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?
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.