6

We just started implementing the Git source control for our project and the Admin says we should not be creating any new branches for the enhancements that we are working on instead everybody should pull remote master branch into their machine and make changes and push the commits to remote master branch.

I somehow feel this process is wrong and I strongly feel that we should be creating new branch for the each enhancement that we are working on and merge the respective branches into master branch. Something similar to this

I need expert advice on this and which approach do you guys suggest from your past experience.

| improve this question | |
  • 1
    See programmers.stackexchange.com/questions/133156/… – Dan1701 Dec 28 '15 at 20:30
  • 3
    Note you are completely free to create as many local branches as you want, for whatever reason you want, without consulting the admin. You just have to rebase them onto master before you push to his repo. In fact, I've done this on git when the official repo is a completely different VCS. – Karl Bielefeldt Dec 28 '15 at 21:00
6

The commit to master or trunk works as long as you are ok with how it works.

It means that if you have committed a bit of code to master (and haven't pushed it because its not a complete thing) and then realize that you need to work on something else (leaving those commits in an incomplete state) - it becomes very difficult to do that.

Branches exist to separate development efforts and the roles that a given line of code may take.

Consider:

  • You are packaging up a release on master, and now everything other than commits for this are frozen. This stops a lot of developers in their tracks.
  • You need to commit a hot fix into master and push it to production.
  • You need to work on two separate tasks at the same time.
  • You need to hold off on committing some features into the master branch until marketing says "ok"
  • Oops, that feature was a mess. Don't commit it to master - oh wait, its already there.

These are just some of the issues that come up with everyone committing to the master branch. If you can resolve these in other ways, then, well, you don't need branches. However, branches are exactly the tool that is used by most processes to resolve these issues avoiding code freezes and awkward reversals of specific commits.

I will also point out that none of this prevents you from having local branches. One could easily pull from master, branch local, rebase on top of master, delete the local branch, and then push that back to the remote master and none would be the wiser. Personally I feel that having branches and merges showing more information about the history of the code is useful, but thats me personally. Maybe your admin doesn't like seeing all those branches and just wants to see the master branch - there are people like that. But that doesn't mean don't branch local - it just means don't push the branches back to the remote and clean up everything before doing that push.

| improve this answer | |
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – yannis Dec 29 '15 at 2:09
4

See the above-linked question for, I think, a comprehensive Q&A on the role of the master branch.

However, to further answer your question, it's important to understand why feature branches are important. If everyone is developing on and pushing to the same branch, then what happens when someone forgets to check in a file, or checks in the wrong stuff, or messes things up in a rebase?

In our organization we use GitFlow, with the master branch left unused. Develop is the working tip of the current release's efforts, releases are in named branches, and features are all developed on (hopefully short-lived) branches.

With feature branches, we're able to run a complete CI build on each branch before it gets merged to develop. Along with an approved pull request, the branch build must be green before the merge can occur. This ensures that the to-be-merged code compiles and passes all automated tests. This process has been successful for us in catching the simplest sorts of problems as early in the development cycle as possible.

| improve this answer | |
0

Maybe the admin is simply trying to get you on board with a continuous integration development strategy, to avoid the integration hell usually associated with multiple development branches.

| improve this answer | |
  • 1
    Are you saying that projects with CI setup cannot use multiple branches instead should use one master branch? – user3978 Dec 29 '15 at 21:31
  • I mean CI as in everyone is working on the same/master branch, which usually has some automated CI tooling on it as well. – Dan Cornilescu Dec 29 '15 at 21:33
  • I did not get your point. Are you saying if everybody is working on the same thing we cannot take the route of creating separate feature branches. – user3978 Dec 29 '15 at 21:54
  • IMHO you shouldn't - you'd be deviating from the CI principles (even if using CI tools in your branches) with all the related disadvantages. The integration hell is one of them. – Dan Cornilescu Dec 30 '15 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.