1.1 What Is Branching

Branches in SCM are also known as Streams or Code lines. Like a branch of a tree is defined as a structural member connected to the tree which is not part of the central trunk of the tree, similarly in SCM, Branch is a part of the mainline, also known as trunk/main.

Branching provides facility to teams of developers to easily collaborate inside of one central work stream of SCM. It facilitates parallel development by providing the ability to work on two or more work streams without affecting others.

When a developer creates a branch, the version control system creates a copy of the code base or the tree at that point in time. Branches may be created for functional reasons too, for e.g., for new features, bug fixes, spikes, releases etc.

The most obvious reason for branching is to start an alternate line of development, i.e. one should branch whenever one cannot pursue and record two development efforts in one branch. The "isolation" purpose is made to isolate a development effort.

1.2 What Is Merging

Merging, in version control, allows you to combine two or more development histories together.  It is also termed as integration meaning integrating branches or versions of a file.

Most often, merging is required when the same file is modified on two different branches and the code/file needs to be merged from one branch to another to bring in the changes of the other branch. The result is a single collection of files that contains both sets of changes.

1.3 Codeline Policy and Branching Strategy

A Codeline Policy defines the set of rules which govern usage of a Codeline. Codeline policies are formed based on answers to questions:

• How is the software released to market?
• How is the development of the software planned?
• What range of software packaging’s needs to be produced?

A Branching Strategy further defines how Codeline policies are to be implemented. Few common considerations in a branching strategy are:

• Identifying configuration items of development that can be easily characterized
• Identifying the differences and similarities between these items
• Narrating how they relate to each other
• Setting parameters for the issues relating to branches creation, interaction, and retirement

1.4 Branching Patterns

Branching pattern are established based on answers to following questions:

• Why is branching needed?
• Where should a branch begin?
• What would the branch represent in the development environment?
• What would be the Codeline policy?
• What would be the merging policy?
• What should be the branch lifespan?

1.5 Mainline Based Branching Pattern

A Mainline is the central Codeline of the project where the code starts its life. As it is the primary lifeline for development, it is central to and has an ancestral relationship to all successive developments.

Mainline based branching pattern can be used for smaller projects consisting of small development teams where everyone is dedicated to one release effort at a time. This works particularly well if there is only one platform for release or the platforms have little differentiation. The development or any kind of bug fix is performed on the mainline with this assumption that there are no chances of code getting destabilized, or no check-points are necessary. It is likely that the development changes would be accomplished entirely in the local view and checked in when finished.

If the project development is performed at multiple geographic locations, it may be reasonable to provide each location with its own mainline and may or may not synchronize their mainlines depending on the type of development. If it does need to be synchronized, then there will be a merge policy for mainline as well. Usually, the mainline will not have to deal with merge policies if it is a single line of development.

1.6 Multiple Mainline Based Branching Pattern

If a project has multiple products based on a common baseline, but otherwise independent of each other, then a Multiple Mainline branching strategy can be applied. In this kind of pattern, the trunk may hold more than one mainline, which would share the same core initially. However, the policies for these mainlines would be differ significantly in terms of their starting compositions and merge policies.

The trunk will have its own release schedule and it will be depending on the project's functioning as to how the trunk's release will be incorporated into products. The other mainline variants branch off from a well-defined version of the trunk's core initially and may be composed of some composite of the core release package their own course of development.

1.7 Release Based Branching Pattern [Major-Minor/Integrated-Minor Release]

Most of the projects need to deal with major or integrated, minor and patch level releases. In such cases Release Based Branching strategy could be used. The Trunk or Mainline holds the production code, i.e. product which has been released. Major or Integrated releases often are characterized by feature and function content changes demanding a significant development which may be accompanied by compatibility issues. It is branched off from the trunk on a specific version.

Minor releases may have new feature development like that of Major releases, however smaller in scale and less or without compatibility issues. These are smaller releases, meaning they durability is relatively small having smaller release schedules, smaller development teams, requiring less time for release completion.

1.8 Release Based Branching Pattern including Patch Releases

Patch Releases, also sometimes known as Hotfix releases, are sub-releases which contains minor fixes to the production code which has already been released. Regardless of any ongoing or future release efforts, patch release work focuses on fixing bugs which cannot be awaited until next Major or Minor release and hence are very short-lived branches.

A patch release may be branched off from the mainline when it has the latest production code (as shown in the above figure), or it may be branched off from the Release branch after it has been frozen and released into production (as shown in the below figure). In either case, once the patch work is complete and released, it should be merged back into the mainline.

1.9 Branching Pattern including 3rd Party vendor code

In cases where client projects work with 3rd party vendors too for development of software products, this kind of branching pattern may be used. It is assumed here that the 3rd party vendor does not use the same SCM Tool or same branching pattern. Instead the code developed by them is imported into the project’s owned source code repository from time to time. This scenario’s complexity may differ as per project’s needs and scalability.

The imported code may be a raw code which might need to be worked upon initially to set it up on the project’s environments. The Upstream branch is kept segregated as it is expected that there will be more imports of raw code from 3rd party vendor as and when development proceeds. The Setup branch is created where in the imported code is worked upon to set up before it is moved into Development branches. A Patch branch is created in parallel to Setup branch, where only patch release code of 3rd party vendor is imported which may not require the setup work. The Development branch which is branched off from Trunk has the ongoing development work wherein the 3rd party code is integrated as well.

The figure below describes a typical scenario of 3rd party code imported from Upstream branch into the successive branches of current Branching pattern.

1.10 Promotional Based Branching Pattern

In a Promotional Model, projects branch-off of each other and have their own set of releases. The logic of such a model may appear easy as the future versions of the product are seen to be built upon the past versions and the physical representation of the flow appears valid.

However, such models are not desirable models for an SCM strategy. It increases the complexity of merge policy when dealing with a Codeline of derivative development or distributed development.

Derivative development is the kind of development which is not performed for product release content but for other causes like proof-of-concept prototype, some research, customized versions; which may or may not be integrated with main product development. Distributed development which is carried out at multiple locations, though have same goals, may be tracked at each location independently and thus may require considerably more efforts to synchronize.

Sunil Khatri

Add comment