Source Control and Branches: branching patterns

Thu, 10/04/2007 - 11:17 — charlie.collins

I am a branching newbie, but so far it's been a good experience. I think the "right" amount of branching, and a clear pattern for using branches, can really help the overall software development process.

http://www.codinghorror.com/blog/archives/000968.html

In a new spinoff project at the day job we have a small dev shop that is using Agile methodologies, Scrums/Sprints, etc, and we are using the "Branch per Task" pattern.

We have only been doing it a few months now, but so far I think it works pretty well. Along with branching though, you really need coding standards (at checkin time, use your own standard as you develop, then format with something like Jalopy to the official "standard," which itself is also checked in to source control), and it helps a great deal to be doing other static analysis stuff (at least when it comes to Java), like FindBugs, PMD, CheckStyle, etc (we have used those tools and had standards for years). Using such tools and having standards can help with the jungle of branches. Well, that and a good pruning technique. If everyone is on the same "page" as to the checked in style, and what to expect in terms of idioms like exception handling, method length, complexity, and more, then the dreaded merge is usually not so bad. And, having a clear branching pattern in mind is the key.

Also, branching helps with code reviews. Branching makes the demarcations of what needs to be reviewed almost automatic. Sure, you can manually select files to review without branches, but it sure is easy if you can just point to the branch.

We use the branch per task approach, then at the end of each Sprint (or before) we merge the tasks back to the trunk and the old branches wither and die. We don't have any long running side branch, and or merges from trunk into branches.

All in all, the Agile practices, with SVN/Branching, and standards, has been a good development road thus far - at least for a small team with some autonomy. Developers seem to agree with the processes (mostly, and they are encouraged to help define the processes), and the resulting work has been pretty good (even in a very difficult environment with many typical big company issues).