ABCs of a Branching and Merging Strategy


Branching is both simple and complex.  For many, it is challenging to know where to begin.  This article hopes to provide a starting point, by highlighting branching concepts, providing reasons for branching, and suggesting an approach to establish a branching and merging strategy.

When establishing a branching/merging strategy and corresponding model, it is important to involve project management since this strategy directly impacts application development. They should be part of the branching strategy decision process, understand the pros and cons to branching, and have knowledge of the effort involved in branching and not branching. This ensures that project expectations are set from the beginning.

It is also important to note that the CM tool being used plays a key role in branching and merging. Some CM tools are better at branching and merging than others. It is important to select and use a CM tool that can support the strategy for application development.

Key Concepts
A branch is an isolated instance of an existing development baseline. Within a branching model, the root development baseline may be known as the trunk and sometimes referred to as the main branch. A new branch can be based on the trunk or another branch. When a new branch is created from the trunk or another branch, the trunk or branch is known as the parent of the new branch.

The items within a branch (whether physical or virtual) are initially identical to the parent. Over time, the items in a branch will evolve and become different to the parent due to the modification, creation, or deletion of the items within the branch.

The reason the terms branch and trunk are used is that they mirror the look of a tree when shown graphically. The figure below illustrates this:



Figure 1

Each branch should have a unique name (e.g., branch A.1) to differentiate it from other branches. The overall branch path should include the trunk name, any parent branch name(s), and the unique branch name (e.g., /Trunk/Branch A/Branch A.1) for clear identification. This not only uniquely identifies the branch, but provides the ancestry of the branch back to the trunk. This information will be beneficial in understanding the relationship amongst branches particularly when items within a branch are to merge with items from another ancestor branch.

<--pagebreak-->A merge is an action that combines an item on one branch with the same named item that resides on another branch. In order for the merge to properly occur, the branches in which the items live must have a common ancestor. For example, foo.c resides on branch A.1 and has been modified. The same foo.c file also resides in branch A and has also been modified. Because both versions reside on branches with the same ancestor (in this case, branch A is the parent branch for branch A.1), then merging may occur.

A label is a tag that affixes itself to specific versions of items within a branch. A branch by itself is generally dynamic, meaning that items can change within it. Applying a label to the items within a branch provides a static identification of the baseline at a given point in time. Typically, labels are placed on items within a branch that represents a milestone however small. This may include a successfully completed engineering integration build, a package for test, or release deliverables targeted for production.


About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.