In software development, the longer you wait to integrate and test your software, the longer it will take to test and ship the product.  For this reason, many development teams have begun to use continuous integration solutions to build the software each time a developer makes new changes to the software.  When continuous integration is used in combination with automated unit tests, the team gains instant feedback regarding any new problems or bugs that were introduced into the software.  By recognizing problems early, the team can fix them before they have a chance to fester.

While this is a very valuable approach, some problems arise when in using continuous integration when the team has many active branches in their SCM repository.  Some of these problems include:

• Continuous integration systems are hard to configure when there are many branches.  Generally speaking, each branch must be configured with it's own build definition file, making it difficult to maintain the configuration when new branches are created.
• Teams lose track of their branching strategy and can't see the big picture.
• Developers aren't sure when to merge changes from one branch to another.
• Merging changes from one branch to another is a time-consuming, manual process.  Developers tend to avoid merging.
• The longer two branches deviate from their ancestor, the more likely it is that conflicts will occur, and the longer it will take to merge them back together.
• If merges aren't done frequently, the benefit of continuous integration is lost.