3 ms·

Code branching isn't required even for complex multi project environments

6 points by janecoder 15y ago

wccrawford 15y ago
Not required? How many things -are- required? I'm guessing the number is near zero. Talk to me about pros and cons, not requirements.
PaulHoule 15y ago
The video puts down "Feature Branching" which is a very specific kind of "Code Branching." I've seen Feature Branching work for some shops, but it can also create problems -- the more complex version control strategy you use the more likely you're going to make mistakes implementing it. The "standard model" for branching that's most commonly used is to do most development in HEAD and make branches for releases. If you spin version 1.1 of your product, you should make a 1.1 branch, which starts with, say, version 1.1.0. If you find a terrible bug in 1.1.0, you can go back to 1.1, develop the 1.1.1 version, and then you can merge the bug fixes back into head. The "standard model" minimizes the number of merges that need to be made while assisting maintenance of deployed software. Other branching models do worthwhile things, but the ratio of merging/benefits is invariably worse.
jeromeparadis 15y ago
I've adopted the following branching model: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ Works like a charm for us. It doesn't mean we don't update production as often as possible but we sure sometime need to push hot fixes to production quickly while working in parallel on new features. I would say branching is a necessary evil.
gte910h 15y ago
For git, code branching is really really easy (even without some tool/model like gitflow). To me, it's like reading "Onions, not required even for complex multi-course meals". Why would you avoid that!
kenneth_reitz 15y ago
This guy doesn't seem to understand that you can merge your main branch into your feature branch constantly if you want. This makes all of his points invalid.

6 points by janecoder 15y ago

Not required? How many things -are- required? I'm guessing the number is near zero. Talk to me about pros and cons, not requirements.

PaulHoule 15y ago

The video puts down "Feature Branching" which is a very specific kind of "Code Branching." I've seen Feature Branching work for some shops, but it can also create problems -- the more complex version control strategy you use the more likely you're going to make mistakes implementing it. The "standard model" for branching that's most commonly used is to do most development in HEAD and make branches for releases. If you spin version 1.1 of your product, you should make a 1.1 branch, which starts with, say, version 1.1.0. If you find a terrible bug in 1.1.0, you can go back to 1.1, develop the 1.1.1 version, and then you can merge the bug fixes back into head. The "standard model" minimizes the number of merges that need to be made while assisting maintenance of deployed software. Other branching models do worthwhile things, but the ratio of merging/benefits is invariably worse.

jeromeparadis 15y ago

I've adopted the following branching model: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ Works like a charm for us. It doesn't mean we don't update production as often as possible but we sure sometime need to push hot fixes to production quickly while working in parallel on new features. I would say branching is a necessary evil.

gte910h 15y ago

For git, code branching is really really easy (even without some tool/model like gitflow). To me, it's like reading "Onions, not required even for complex multi-course meals". Why would you avoid that!

kenneth_reitz 15y ago

This guy doesn't seem to understand that you can merge your main branch into your feature branch constantly if you want. This makes all of his points invalid.