To Branch or Not To Branch (and Merge/Test)

of this really doesn't have a lot to do with branching, but it does have a lot to do with change management - introducing change with minimal impact. And design architecture will certainly make a difference here. So I would then look at which pieces of the change are going to most likely hit the same files that are going to be changing in the current stream or in parallel in the next stream, and would try to introduce those changes rapidly, if possible, again with run-time switches, where necessary, to hide their impact.

OK. This might not be addressing the CM of the problem, but it is an important part of any complex implementation task - minimizing impact and minimizing parallel development.

Second, if there's not likely going to be a lot of parallel work required in the development stream for which the change is targeted, I would perhaps just use the next development stream's branch to implement and to reconcile current development stream changes into. In effect, the next stream's branch becomes the "task branch."

Third, if the above were not feasible or easy, I would consider a parallel branch for the effort - and initially target the new branch to a "feature" stream. This sort of thing may not be going on all of the time, so you may be able to use a generic feature stream; otherwise, you may need a specific "featurexyz" stream. Use that branch to develop and reconcile, while sharing the work with others who want to pick up your changes. After the final feature implementation and reconciliation, I would likely merge the final product into the target delivery stream (i.e. branch).

This latter case, is indeed a task branch pattern, but the task branch isn't created for every task... just for those which really need it. And depending on the task, I very well might recommend not working in isolation, but, having analyzed how to introduce the change into the development/product stream, might encourage checking in safe changes directly to the target stream branch as they're ready. Now that goes against the premise of the question, but on the other hand, I've seen this approach work successfully to help minimize parallel development and subsequent retesting, while at the same time helping developers to learn how to introduce incompatibilities and complex changes into a product. And if fact, this works quite well if used with change promotion states. Changes can be entered into the target stream and promoted to a group level, for group builds, until ready for the system build. By having an intermediate group promotion level, group-based builders can build deliverables for use and first level testing within the group. Other changes intermingled with the task specific changes would be stuck at the group level until all dependent changes could be promoted. This does not necessarily have to be when the entire task is ready, as per the discussion above.

Minimize Parallel Changes

There's another way to eliminate branching - minimize parallel changes. This can be done in many ways. Intelligent scheduling and change analysis across the project plan can help. But likely the two most helpful tools here will be design architecture and minimizing check-out duration. Speaking to the latter case first, if your CM tool forces you to keep things checked out for fear of breaking the build, it is also going to encourage parallel checkouts, and perhaps the need for parallel branches. On the other hand, if you can check code in without it going directly to the build, you can considerably shorten the checkout window, eliminating the