ABCs of a Branching and Merging Strategy

Summary:

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.  

Key Concepts

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: 

mmnov03-1

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. 

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.

Branch A.1

Branch B

Branch A

Trunk

(main

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

About the author

Mario  Moreira's picture
Mario Moreira

Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at http://cmforagile.blogspot.com/ . You may reach Mario by email at Mario.Moreira@cmcrossroads.com.