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 and 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 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.
What is a ‘branch'? 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 with the parent. But 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 why the terms ‘branch' and ‘trunk' are used is that they mirror the look of a tree when shown graphically. The figure below illustrates this:
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.
What is a ‘merge'? 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 occur properly, 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.
What is a ‘label'? 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 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.
Reasons for Branching
Should you Branch? In a nutshell, the primary reason to branch is if concurrent or parallel development must occur. This is described as the need to perform two or more isolated lines of development on the same baseline of code but for different purposes.
If there is a need for branching, a project release branch may be used