I have to say I am a fan of branching for feature or for team. I think branching for feature, or branching for a Minimal Marketable Feature (MMF), really fits into the Kanban model.
However, decouple first. This article was really good about talking about a decoupling branching strategy.
Once decouple, branch by feature or in the Kanban world, Branch by MMF.
Here are the positive and negatives.
Branch by feature or team (team and feature are similar)
- http://lostechies.com/derickbailey/2009/07/15/branch-per-feature-source-control-part-1-why/ (shout out to Kanban)
- http://msdn.microsoft.com/en-us/library/bb668955.aspx (this has a nice description of different branching strategies)
Having read all of these. The negatives are important to read.
It seems that a lot of the negatives are eliminated by the following.
- Decoupled code
- Using Interface-based design (which is a method for decoupling code)
- Keeping MMFs as small as possible (which they should be anyway: “Minimal” marketable feature
- Merging main to the feature branch daily/weekly
- Running tests on CI on feature branches as well as on main
- Checkin’s are gated so a failed build/test prevents check in.
Also read the comments as there are real experiences shared there (assuming the author of the comments are sincere).
A successful branch by MMF strategy can be done with any source control tool.
Side Note 1:
I’ve been using GIT lately for a project in my Masters of Computer Science’s Security course. I finally understand why GIT has become the de facto source control for Open Source, because branching on your local machine can be helpful and efficient. The local check out on your dev box IS A BRANCH and can be branched and you can branch by feature or by task locally.
I recently wrote something I couldn’t check in and couldn’t branch it locally with our source control, but I could have with GIT.
Side Note 2:
Another side note: TortoiseGit and TortoiseSVN are both on my dev box now and explorer.exe is constantly at 45% CPU slowing my system.