I used to think that branching was awesome. And then I realized that what was REALLY awesome were small, atomic commits. They are the thins that make code increments readable and let you find the problems better.
Branches are good for isolating longer-running changes but the merges are often not small. The longer the branch the more chance the merge will introduce subtle bugs. And the merge has so many lines change, where do you begin to see where the bug is once you've combined branch A and B?
I've had a coworker argue that NOT having long lived branches avoids this. And he said at Microsoft they were just fine with mainline - and as soon as they started branching the trouble always started during the merge.
I guess it's a combination:
a) Granular commits are an essential basis of good version control. Big, bloated commits (maybe even combining code from multiple, different topics) will sooner or later bite you.
b) Integrating often. I think you can be successful with long-lived branches, but you need to have more discipline and not forget to re-integrate from time to time. Integrating late will naturally raise the risk of conflicts - because, simply, more changes accumulate.
Branches are good for isolating longer-running changes but the merges are often not small. The longer the branch the more chance the merge will introduce subtle bugs. And the merge has so many lines change, where do you begin to see where the bug is once you've combined branch A and B?
I've had a coworker argue that NOT having long lived branches avoids this. And he said at Microsoft they were just fine with mainline - and as soon as they started branching the trouble always started during the merge.
So what about that?