Branch-Per-Feature Source Control. Introduction


I have used the term ‘branch-per-feature’ very loosely until recently. It was a catchy name, easy to remember, and got the point across. However, this is only one example of what is really a branching strategy.  A branching strategy is nothing more than an understanding of when you should branch your code and when you should merge that branch, where.

With that in mind, I feel the need to reorganize and rewrite many of these posts, as the information is applicable to more than just branch-per-feature. However, I don’t know that I would have time for that. Maybe I’ll get to it some day… maybe I’ll rework all of this as part of a book at some point. Maybe maybe maybe… just note that the processes and theories I provide here are easily extracted into principles that can be applied to most branching strategies.



I’ve been meaning to write up a post on Branch-Per-Feature for a very long time now – nearly a year, actually. I’ve been seeing a lot of twitter about this idea, recently, and have done a poor job of assisting those who are asking questions. Today, though, Tim Ottinger finally convinced me to get off my butt and get it done. So, here it is… well… here’s the index and introduction for a multi-part post series, anyway.

What Is Branch-Per-Feature

At the heart of Branch-Per-Feature, is the notion of using source control in a manner that allows multiple teams or individuals to work on the same software system without clobbering each other with change sets. That is, we should be able to work in a manner that allows Feature Team A (FTA) and Feature Team B (FTB) to work independently of each other. FTA should be able to analyze, code, test, and deliver their feature without any regard for the work that FTB is currently engaged in. When either team is finished with their work, the other team will merge the now stable feature changes into their branch, and continue on from there.

The Article Series

As I began writing up the initial post on Branch-Per-Feature, I recognized the significant amount of information that I was trying to dump onto the world, all at once. While I do believe that all of what I am going to say is useful and beneficial, I also think that it would be better for the community if I split the information into more logical chunks. This will allow the individual reader to more easily find information that they are looking for, without having to wade through page after page after page of information that they don’t want at the moment.

The following is the outline of posts that I am planning for this series.

  1. Branch-Per-Feature Source Control: Why
  2. Branch-Per-Feature Source Control: How (Theory)
  3. Branch-Per-Feature Source Control: How I Manage Subversion With Git Branches
  4. Branching Strategies:
    1. When To Branch And Merge
    2. The Cost Of Branching And Merging
    3. Handling Dependencies Between Branches
    4. Database Considerations
    5. Continuous Integration Per Branch

Other branch per feature and branching strategy posts out there on the interwebs

  1. Branch-Per-Feature in Subversion (by Darrell Mozingo)

The “Lessons Learned” information may find it’s way directly into the individual posts. However, I’m hoping to collect all of these into a single post, specifically, at the end of the series. Be sure to check back to this index page on a regular basis, for updates in the series. I’m planning to get the series done in a fairly short amount of time (a few weeks, at the most) so that I don’t lose my momentum or motivation.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Agile, Branch-Per-Feature, Branching Strategies, Continuous Integration, Git, Source Control, Standardized Work, Subversion, Workflow. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • We’ve been doing BPF for awhile now and I have to say I’ve grown to love it.

    Its also good for training new individuals on your systems. You create a sandbox branch and put in some bugs for them to find and fix.

  • We’ve actually been using what could be considered a branch per feature approach using Subversion (and CVS) before it for a couple of years now. It allows us to have numerous developers working on a variety of task simultaneously without impacting the trunk. It can be a little painful when it comes to to merge, and seem like overkill on smallish features but its working for us.

  • Its been few months now since we started following BPS – Branch Per Scrum. And that has made perfect sense in delivery and quality. Not just that, it has saved us a lot in terms of code versioning + tracking and review. All we have to take care at the time of merging the branched code with main branch.

  • Graham

    Isn’t the whole point of doing CI to remove the pain of doing large merges caused by working separately for long periods of time? In which case isn’t this a huge step backwards?

  • @Graham,

    Only if you assume that you are working in large batches. Understanding how to size your work appropriately is an assumption that I’ve made in the first few posts, but am going to make a little more explicit in post #3 – strategy.

    “Continuous Integration” is very often misunderstood, in my experience (not saying you misunderstand it… making observation about the development community, as a whole). In a future post, I’m going to outline how I do CI-Per-Branch… how i do true continuous integration, not just “continuous compilation and test execution” … which further mitigates the issue that you’re describing.

    I certainly don’t want to claim that BPF is a magic silver bullet or anything like that. It’s good to know the circumstances in which it works best, and in which it fails.

    thanks for the feedback. I need this kind of dissent and discussion. it helps facilitate the information that i put into the posts.

  • @Dhananjay,

    I assume you mean branch per sprint or iteration? that’s an interesting variation. I think i’ll include that as an example in my next post (strategy) where I discuss what/when to branch and merge.

  • nice article. Totally agree with you on the Branch-Per-Feature Strategy. Looking forward to your 3~8 of this serial.

  • Jpt

    Nice Series, if you could finish: Database Considerations and Continuous Integration Per Branch, that will be awesome…