4 ms·
Ask HN: Are Branches (SVN/Git) Evil?
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 "If you need branches, your development process is broken."
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/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't actually lower the quality.
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).
What do you think HN, are branches indicative of a "broken development process"?
- oxalo 12y agoSimple 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 12y agoThanks 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 12y agoAnd 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.
- cratermoon 12y agoWith svn, maybe. With git, pretty much everything is a branch.
- tylermauthe 12y agoI do miss git -- for exactly this reason ;)
- tylermauthe 12y agoI 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.