

Code branching isn't required even for complex multi project environments - janecoder
http://www.thoughtworks.com/perspectives/30-06-2011-continuous-delivery#face-to-face?contactID=159080380&gwkey=ED3OMQ5XR9

======
wccrawford
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
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.

------
gte910h
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!

------
jeromeparadis
I've adopted the following 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.

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

