Code Leader: Using People, Tools, and Processes to Build Successful Software

6.4. Making the Most of Branching

Branching is the one aspect of source control that is most often overlooked, underappreciated, misunderstood, or abused, depending on the environment. To create a "branch" (sometimes referred to as a "codeline") in a source control system is to split a source tree in two (or more) "branches," each of which descends from a common ancestor. Changes made in one branch are not reflected in the other branch(es). This means that you can split one project into two or more projects simply by creating new branches in your source control system. This is most often done for the sake of continuing work on the latest code (the "tip" or "head" revision) while preparing to ship an earlier version in which changes need to be restricted. These "version branches" are the kind most often encountered in software shops, and the most readily understood by developers.

There are several other very good reasons for branching, however, that are less widely known. "Personal branches" allow developers to continue to check in incremental changes without affecting the integration branch. They provide an excellent place for developers to experiment, try out ideas, and work on XP-style "spike solutions." "Task branches" can be used to identify all of the work that went into a single task/backlog item/story. They serve as a macro-level change set, grouping together a set of changes that span multiple commits to the repository that are all related to a single task.

An "integration ...