ABCs of a Branching and Merging Strategy

[article]

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 to isolate the project work from the main line which may represent what is in production (therefore, you would not want to 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. Working 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).

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/.
 

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

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