

Ask HN: Are Branches (SVN/Git) Evil? - tylermauthe

Recently, I had a discussion with two colleagues (who are far more experienced than I am and whom I respect a great deal). The topic of the discussion was Branching Strategies and when to use them. They made the argument that good developers do not need branches, if I recall correctly the statement they made was &quot;If you need branches, your development process is broken.&quot;<p>Their reasoning for this statement is that all code changes can be made in small increments and be done in such a way to preserve existing behaviour while allowing new development to occur. This can be achieved in a number of ways, for example if&#x2F;else statements where the else branch contains the new feature but is not executed (except when the dev changes the expression to return false). By this line of reasoning, it follows that any new or dev commits which lower the quality or reliability of the code will be in some code-path which is deactivated and so they won&#x27;t <i>actually</i> lower the quality.<p>In summary, my argument for branching was you can use branches to help to ensure release quality (ie: have branches for master, release and development) by segregating changes in SCM according to whether they are under active development, ready for release or currently in production. Their counter argument was that ALL changes in SCM should be production-quality and be ready to release at any second (and if not, you should change your dev process).<p>What do you think HN, are branches indicative of a &quot;broken development process&quot;?
======
oxalo
Simple answer, no.

If you're using if/else all over the place instead of a branch, what's to stop
you from forgetting to remove one when you decide your new work is 'production
ready'?

At the easiest level, I'd suggest using branches for new development. Bug
fixes, new features, etc. Keep the work small; branches are cheap. Once its
reviewed or tested merge it back into the master branch. This way 'in
development' and 'complete' are abstracted to a level above code.

Also, imagine your project has 30 developers, or more. Would the strategy of
if/else everywhere still work well?

~~~
tylermauthe
Thanks a lot for this answer. Good point about keeping the branches small and
about having only two.

The team I work on is quite small, so I can see how not using branches can
work. I've worked on larger teams and I can't imagine how we would have
managed those changes without an excellent branching model (git-flow).

~~~
oxalo
And that's the other thing: use what works for your team. If you have an idea
on how to make it better, try it. If something isn't working well, change it.

------
tylermauthe
I thought I'd throw and update on this.

[http://martinfowler.com/bliki/FeatureBranch.html](http://martinfowler.com/bliki/FeatureBranch.html)

After reading this article, I now realise why having only one branch is
desirable for a small team using CI. The development style should use things
like feature toggles to ensure that code paths are not activated.

Branching, as I've thought of it, relies on the SCM to segregate features
instead of developing robust and modular features that can be swapped in/out
willy nilly.

------
cratermoon
With svn, maybe. With git, pretty much everything _is_ a branch.

~~~
tylermauthe
I do miss git -- for exactly this reason ;)

