ABCs of a Branching and Merging Strategy


corrupt production with less than production-ready code). This is branching in its most simple form, however, there are more complex reasons for branching.

Reasons for parallel development at a project level may include (but not limited to):

·       Working on two or more project releases (this may include major releases, minor release, customer specials, prototypes, platform conversions, etc.)

·       Working on a project release and on bug fixes/patches for a previous release(s)

·       Reasons for parallel development within a project may include (but not limited to):

1.       Working with other sites (site specific branch)

2.       Working with several colleagues at the same site (shared branch)

3.       within a private workspaces (user specific private branch)

There is no limit to the number of branches that can exist. A branch and merge strategy should be designed prior to creating branches, though, to first ensure that branching is needed and secondly to ensure that the branch structure under consideration will work for the project. Too many branches may make development too complex to follow and too few branches may constrain development.

Many project teams perform development from the trunk or main branch because they follow the serial development approach. However, some project teams end up performing some level of parallel development on the trunk or main branch and this is where problems may begin. The important point is to recognize the need for branching before and prepare a strategy for it. Conversely, many project managers make a decision to perform parallel development, but are not sufficiently informed of the complexity and effort. It is the job of the SCM professional to raise this awareness so they can understand the appropriate reasons for branching (or not branching).

Types of Branches

There can be various types of branches. As mentioned in the previous section, the branch structure starts with the trunk or main branch. Beyond this, the branch type should depend on the need. Some branch types may include (but not limited to):


·       Project branch: If the project is large, then this branch may be used to merge stable pieces of code. If the project is small, than this branch may be used as the integration branch for all development changes. This branch type may be used when stability is needed and would be used in conjunction with an integration branch. It is typically backed by the trunk.

·       Integration branch:   May be used as the active development line to integrate development changes. This line of development may not be stable depending on the amount of merging occurring into it. It is usually backed by a project branch.

·       Shared branch: Similar to an integration branch but used by a subset of developers working on a more volatile set of code such as performing prototyping so it does not impact others until it is sufficiently tested. It may be backed by an integration branch.

·       Site branch: Similar to a shared branch, it may be used when there are other sites involved in development. This isolates their work but still allows for merging to the integration or project branch. It is usually backed by an integration or project branch.

·       Private branch: May be used to isolate individual developer's changes from each other. This may be backed by a site branch, shared branch, integration branch, or project branch. In fact some of the private branches may be backed by a shared branch and others may be backed by an integration branch.

·       Bug fix/patch branch: A branch that is used

About the author

Mario  Moreira's picture Mario Moreira

<strong>Mario Moreira</strong> 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 “<strong><a href=";camp=213761&amp;cre... Configuration Management for Agile Teams</a></strong>” (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, “<strong><a href=" Configuration Management Implementation Roadmap.</a></strong>” 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 <a href=""></a>.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!