In my last 3 engagements, I’ve been asked to help my clients with creating a branching and merging plan using code promotion for release management. Since I’m not at a client site today, I figured it was a good time to actually put down my thoughts on branching and merging strategies. First off, before I begin, I would like to add a word of caution. Any time you branch, you add a significant layer of complexity. In TFS, it’s extremely easy to create a branch. You just right click a folder and select branch. However, to maintain the branches, the additional testing required, and resolving the potential merge conflicts between branches does add complexity (and not just a little). The pain of the additional work required with branching need to be far less than the pain of not having the branches. In other words, don’t branch unless you really need to. So when do you really need branching? Actually, this is an easy question to answer. If developers start doing weird things to work around restrictive check-in policies, it’s a good sign that an official branching strategy needs to be implemented. For instance, if there is a code freeze on the main branch for V1.0 and developers are creating copies where they can continue working on V1.1 changes, that’s a good sign that you need branches. If your developers can’t check in their code, they have to shelve their code because their check-ins are going to drastically affect everybody else, which would freeze development, that’s a good sign a branching strategy needs to be implemented. If a developer refuses to do a get latest, just works in his own little world, and when he’s finally finished, he checks in his code (which results in a hellish couple of days trying to integrate his code back with everyone else’s), that’s a good sign you need a branching strategy! In a nutshell, if developers don’t have the branches they need in source control, they WILL create them on their hard drive. So if you catch your developers creating ad hoc, unofficial branches on their hard drive, it is definitely time to create a branching strategy!!!In Abel’s World, I use 3 different branching strategies. A simple branching strategy. A branching strategy used to support hot fixes (and service packs), and a multi-team/multi feature branching strategy. We’ll start with simplest. A common scenario I see is that a software shop starts off extremely small. One or two developers, long development cycles, and infrequent releases. Since it’s just a couple of guys coding like mad men, they have no need for a branching strategy. They are all coding off of a single branch. And for a small shop like this, it works just fine. Inevitably, things start to change and grow. More developers are added, releases come a little quicker and problems and bottlenecks start occurring. One problem often encontered is developers check in code which haven’t been adequately tested. Another common problem is that the code base becomes EXTREMELY volatile right before a release. This makes QA-ing the application, or even figuring out what is going to be released extremely difficult. To alleviate this problem, the team implements a code freeze where developers are not allowed to make code changes. These code freezes might start out as just half an hour, but they soon turn into longer and longer periods of time where developers are not allowed to make changes to the source. In a situation like this, a simple branching strategy can be used. I take the MAIN branch where developers are currently working, and from there, I branch to a DEV branch. Now, all the developers will do their work in the DEV branch. 
As time goes by and DEV becomes closer and closer to feature complete, they need to merge the changes over to MAIN, where the QA finds bugs. Developers continue working in the dev branch, fixing bugs, working on new features, merging those changes over to MAIN until QA determines that it is feature complete and the quality is good. At that time, you create a branch from MAIN to have an archived copy of what the source code looks like for the version release. I like keeping my MAIN branch as stable as possible. I try not to merge code from DEV to MAIN until the code in DEV reaches a certain level of quality, and is believed to be ready for production. I then merge those changes to MAIN where QA bangs on it and gives it their blessing. I also like having a CI-Build running on the DEV branch, and a Nightly build running on the MAIN branch. This way, developers checking in code will quickly realize if they are breaking the build in the DEV branch, while the nightly builds in the MAIN branch is a nice sanity check to make sure everything compiles and passes unit tests and BVT’s. So the above demonstrates how the code branches, but this is different than how I want to lay the branches out on my hard drive (or in source control). I want to be able to take one look at my hard drive, or source control and know exactly where I am. Here is how I would lay out the source control:
$/ProjectX/Main
$/ProjectX/Main/(all the files and folders for the application)
$/ProjectX/Development
$/ProjectX/Development/(all the files and folders for the application)
$/ProjectX/Production
$/ProjectX/Production/V1.0
$/ProjectX/Production/V1.0/(all the files and folders for the application)
$/ProjectX/Production/V1.1
$/ProjectX/Production/V1.1/(all the files and folders for the application)
Now before I finish this section, I would like to address a question a good friend and colleague asked me. “Why do you branch from Main to Dev, why not use the original branch as the DEV branch and branch to a new branch and call that QA or MAIN? Or if I’m just starting the project, why do you create a MAIN branch first, and branch to DEV?” The reason is because I want to keep a consistent forward merge and reverse merge pattern. Also, branching like this allows for a seamless integration into future branching/merging patterns. Future branching patterns will not have to use baseless merges. More on that next time. For my next blog installment, I will talk about a slightly more complex branching scenario. Branching for the ability of hot fixes, or even hot fixes and service packs. –a
