How is branching in Git more effective for developers then regular commit/push/pull cycles?

Question

I have been using git for some time now, and i like it, however, I generally use it in the cvs/svn style (i dont branch/fork unless I don't have access to the head).

I find that the commit/pull/push cycle is effective: if I have conflicts, I usually just checkout a fresh copy of the source, remerge my changes, and move on. Of course, if I edit a hotspot in the source tree, there are issues --- but i assume that this is a problem with any multi-developer source control workflow.

So my question is: how can I begin to realize the added value which git "branch" development workflows yield, compared with cvs style, centralized commit/pull/push development cycles? In general, do we see a rise in productivity when adopting such staple git-style development practices?

Answer 1

• You can work on your branch without pushing to the central repository (and having it) autonomously for more than one commit, preserving meaningful history
• You can work on the project without actually having access to the central repository and contribute back by exposing your branch
• You can merge and cherry-pick back and forth between branches and your merge history will also be recorded (I've heard svn does it as well now, but haven't worked with newer svn).

Most of it should be possible with newer svn if it indeed records merges, but emulating this workflow on a remote centralized repository is also slow.

Answer 2

In a one-branch model, there are only two possibilities for large changes:

• The large change gets checked in as a single commit. This is terrible, the person working on the change won't be able to use source control until the entire thing is finished. If the change takes four weeks, that's four weeks without source control. (Imagine if you want to work on two different workstations during those four weeks...)

• The large change gets checked in as several commits. This is terrible, anyone who checks out the code in the meantime gets a broken tree. If the change takes four weeks, that's four weeks where nobody else can get anything done.

The only viable solution is to branch and merge.

Note: I hope that was a typo in your post. The correct cycle is commit/pull/push. Don't push your changes until you've merged and tested the resulting merge. Otherwise you are just giving untested code to other people, which will earn you nothing but pitchforks and torches.

Answer 3

Branching is in fact quite important. Imagine you and your colleague are each working on a feature. It takes both of you a couple of days to write the code. In the meanwhile, you would want to compile your own code and test it, without having broken code introduced in your program by your colleague. Branching helps you keep your own modification to the source separate, until you decide to merge them.

Another example could be that you reach a point that you want to release your software and you need to put it under extensive test/debugging. In the meanwhile your colleague has already started working on the next version. Branching here helps you keep the older code being tested and the code under development apart.

You could take a look here for an interesting usage pattern of branches.

And with Git, you don't need to be afraid of merging. If you have ever tried intentionally creating a conflict and then resolve it, you would know it is simple. In reality, unless two people have contributed extensively to the exact same part of the code, resolving the conflicts is not such a big deal.