I'm a amateur programmer, I'm not used to working with Git. It's my job to help test new code, for a while now this has included pulling the branch containing the issue, merging it with the main branch, and pushing it to the test environment.
There are a lot of steps involved with a incredible amount of different options that are of no use to me. Since I always pull from and push to the same two servers, all I'm really doing different every time is selecting the branch for the issue that I'm testing.
My question basically is: Which practice is considered state-of-the-art to make this easier? I can't be the only tester with this problem, what are some solutions to this? Should I get a command line version of git running and see if I can script the basic steps?
Note: step three in this post seems to be roughly what I'm looking for but there is no elaboration on how the asker plans to do this.
-
2software recommendations are explicitly off-topic per help center. See meta.programmers.stackexchange.com/questions/6483/…gnat– gnat2016年01月07日 11:23:40 +00:00Commented Jan 7, 2016 at 11:23
-
1yes, script is always a good solution.gbjbaanb– gbjbaanb2016年01月07日 11:52:49 +00:00Commented Jan 7, 2016 at 11:52
-
2It feels like you are having to do 1 step too many to me, and the developer is doing 1 too few. I think when he is ready to pass to you, the developer should merge from master into the branch. Then you can push the branch to test.ozz– ozz2016年01月07日 14:16:20 +00:00Commented Jan 7, 2016 at 14:16
-
5Shouldn't "merging with the main branch" be something the developer of a specific feature does for you? What happens if a merge conflict occurs which has to be resolved manually?Doc Brown– Doc Brown2016年01月07日 15:32:07 +00:00Commented Jan 7, 2016 at 15:32
-
What @ozz and Doc Brown have said. It is the responsibility of a dev to make sure his feature branch is up to date and ready for testing. If it isn't, you yell at him. Also, any merge issue have to be resolved by the dev. I work on a project with multiple testers doing manual tests (mostly). All of them have their own instances of the software (it's a web app, so a separate code + vhost). Each tester can at any time update his instance and/or switch to a branch. We did this with Gunnery . Think of it like a script with a nicer interface + users.rszalski– rszalski2016年01月07日 21:02:58 +00:00Commented Jan 7, 2016 at 21:02
2 Answers 2
If there's no continuous (or partially automated) delivery system in place, it's a job of a software developer to provide a test build for a tester (it might be your boss who needs to know nothing about command line git). If that process is really tedious to repeat, the way would be to automate it with some scripts. Most likely it involves using command line git, and should be done effectively by someone who has this knowledge. Such script could be run as a git hook, or as a part of some continuous delivery system.
As a tester, it's the developers' job to provide you with a build that is going to be tested, and you have absolutely no business producing any code or merging any code. Whoever merges a branch with the main branch must be a developer.
The usual method is that a developer develops on a branch, provides you with a build based on that branch, and you test it. Once that is done, and the code is also reviewed, and it is decided it's the right time for it, the developer moves his code in the main branch. And you test the main branch before it is released.
Usually the developer will merge the main branch into his own branch before giving it to you for testing. The reason is that when finally the developer merges his branch into the main branch, there will be less chance for conflicts.