ABCs of a Branching and Merging Strategy

Establishing a Branching and Merging StrategyWhen 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

1.1

1.0.1

Private Branch

Bugfix Branch

Project Branch

Trunk/Main Branch

1.0

Complexity Over TimeHow 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.