ABCs of a Branching and Merging Strategy


to perform bug fixes or patches to an existing release. Any changes in this branch should not only be merged ‘in' to the trunk (presumably for production), but they should be merged out to any new project development (via the project branch, integration branch, site branch, or private branch) so that the fix is included in the new release so regression in functionality and stability does not occur.

Below is an example of a branching and merging model which uses some of the branch types listed above.




Figure 2

Establishing a Branching and Merging Strategy

When considering a branching and merging strategy, you must first understand that the application branching requirements will evolve and what is adequate today, will not necessarily meet the branching needs in the future. Therefore, it is important to think about the application's short-term and long-term branching needs when defining a branching strategy. This involves considering three aspects: complexity over time, effort, and risk to stability. Once these aspects are considered, a branching and merging model may be created that can support the application.


Integration Branch



Private Branch

Bugfix Branch

Project Branch

Trunk/Main Branch


Complexity Over Time

How complex is the application development and how complex might it become in the future? Some key components to complexity are (and not limited to): 


·       The number of users involved.

·       The type of users that may be involved (developers, testers, build/release engineers, etc.).

·       The amount of parallel development that may occur (number of releases occurring in parallel, bug fixes occurring on past releases, whether other sites are involved, and how much prototyping is occurring).

·       With the complexity in mind, consider how the complexity will change over time. For example:    Within the first 6 months, project release 1 may include only 5 developers, no parallel development, and only 1 site involved in development.    After 1 year, project release 2 may include 15 developers with parallel development to manage release 2, bug fixes for release 1, and a prototype for release 3, and includes 2 sites involved in development.

Clearly, there will be a need for a more advanced strategy needed for the second scenario. This is why capturing complexity over time is important. The complexity will drive the branching needed and thinking ahead will ensure what is in place today can be easily extended to support the application needs tomorrow.


As parallel development is introduced, the level of branching complexity increases. As complexity increases, the amount of effort to manage change within a more complex branching environment increases. This should be an expectation that project management understands and plans. If they do not, ensure you advise them of this fact.

This is the trade-off of going to a parallel development model. While it may enable faster-time-to market, it may also increase the amount of effort and coordination in certain stages of the project and in particular adds merging and testing tasks to the project plan. Keep in mind that merging typically requires retesting to ensure that the code merged is tested appropriately, particularly where logical lines of conflict have to be reconciled.

Another aspect to considering effort is the project management strategy as it relates to the delegation of development work. If specific chunks of work are allocated to specific groups, then less merging and testing is likely to occur. However if the project manager is indiscriminate in the way the work is being doled out then a significant amount of merging may occur increasing the amount of effort and quite possibly

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!