Version Control Through Branching And Merging

Published Date: 02 Nov 2017

Version Control

through

Branching and Merging

Abstract

In today business, companies are looking forward new ideas to develop and in this aspect they need to know the better path to invest. And sometimes the feasibility studies does not give an accurate result whether to take the initiative of a new project or not. Agile management with its methodologies, disciplines, tools and features is a very good approach to production; helping the process to achieve aggressive market delivery targets while maintaining cost structures on current economic conditions. Usually is hard to pick one method from the others for the actual project type, may be you would wonder what about merging one or two methods, or even take the best of different methods depending on your unique scope, circumstances, project resources and boundaries. One of the principles of Agile Manifesto is Start Small and Grow on the way, gives the opportunity to prototype in early phases giving the possibility to the customer to withdraw or continue with the project. The whole development lifecycle encounters difficulties like parallel tasking in cases of; multiple teams working on the same or different features, different activities happening for the same scope of work, many releases required while the main work cant be stopped and a lot of other situations. This paper will give an overview and start a research for finding a version control strategy, pattern or model based on the best practices and fundamentals of existing ones. Software change management is facing bigger challenges nowadays, while the development market is moving to other countries like India, China… Countries which have different time zone and different culture than our daily environment. The tools for version control beginning with Concurrent Versions System (CVS), Apache Subversion (SVN), Git, Mercurial has arisen lately Version control (also called subversion control, or revision control) helps large projects from spinning out of control by letting individual programmers (or writers, or project managers), each tackle a project from a different angle without getting in each other’s way and without doing damage that can’t be undone.

Contents

Introduction

This paper is basically developed upon Agile principles, specifically SCRUM project management methodology, XP programming as an Engineering Method. Previous information to these topics are required to understand the following text, as the purpose of this paper is to branch and merge activities and piece of work in order to offer a flexible environment to welcome change and quality.

Except for the two mentioned technologies, it will be completed to read any further information about Continuous Integration as a mainstream technique for software development. References will be found at the end of this paper.

Acronyms and Definition

UAT User Acceptance Testing

QA Quality Assurance

XP Extreme Programming

Branch is an isolated instance of an existing development baseline. Within a branching model, the ‘root' development baseline may be known as the ‘trunk' and sometimes referred to as the ‘main branch'. A new branch can be based on the trunk or another branch. When a new branch is created from the trunk or another branch, the trunk or branch is known as the ‘parent' of the new branch.

Shared branch is 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.

Trunk is the mainline of the project, every developed feature, fixed bug must merge to trunk.

Tag is the release point, all releases should go from the tag.

Development branch is the branch where development occur, it must be merged to trunk very often when the team has finished coding..

Release branch (QA branch) is the branch to do testing and bug fixing before the release. When the branch is stable, it will go to a tag ready for the release.

Bug fixing branch is the branch while bug fixing occur when a bugs are found on production or during the development cycle.

Why Branching

In an environment while team is scaling or releases become very flexible, the common reason for creating a branch is to support parallel development or other activities to improve the process. In a more philosophical view of what branches represent, they are actually workflows for different aspects of the software development process that go beyond regular parallel development practices. In this case different teams working on different features in the same project or different ones, while integrating in the same main line (code base) will have the need of "forking" for software versioning. The versioning will help different disciplinary teams work on separate features and activities while preserving their changes.

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.

Except for increasing team productivity, branches are also created for many needs like expressed below. Some of these types of needs might be:

Maintenance release – A branch created for a previous patch release of the software

Customer customization – A special version of the software just for one customer

Development branches – Developer branches to test code not ready for Quality Assurance(QA)

Code configurations – Different configurations of the code based on an environment, such as

UAT, QA etc…

Special content – Content that might not fit under the same code structure as source code,

such as images, db, binaries or static content

Working with other sites (site specific branch)

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

Working within a private workspaces (user specific private branch)

There is no limit to the number of branches that can exist. However, a branch and merge strategy should be designed prior to creating branches 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 team’s 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).

While Branching

As we will mention in further writing there are several facts and challenges during the whole process. Some of the golden tips can be summarizes as below. Strictly keep the main line (or trunk) in a stable status. All the features should be compiled and verified while keeping in mind Test Driven Development. At any given moment it should be possible to launch a release. Preferably the continuous build system should build and auto-deploy to a test environment after the daily work.

Tag each release. Whenever you release to acceptance test or to production, make sure there is a version tag on your mainline identifying exactly what was released. That means you can, at

any time in the future, go back and create a maintenance branch from that point.

Create new branches only when necessary. Branch off a new codeline only when you can’t use an existing codeline without breaking that codeline’s policy. When there are doubts, don’t branch. Why? Because each active branch costs in administration and complexity.

Use branches primarily to separate different lifecycles Maybe each Scrum team code has not their own codeline. But if you mix short-term fixes with long term changes on the same codeline, you will find it very difficult to release the short-term fixes.

Synchronize often. While on a branch, synchronize to mainline whenever there is something that builds. Before the daily work, the team should synchronize from mainline to its branch, so that their branch is up-to-date with respect to other team’s changes. Most of the times there are a huge merging errors coming up, but it’s better to face then earlier than waiting for the long lasting integration (synchronization).

Branching Strategies

To have control and manage efficiently a project you need to choose the suitable branching strategy. Branching is a very crucial part of software configuration management. If this is properly setup, it will guide you to a successful parallel working, synchronized releases, code integration and testing; also bug fixing.

If you don’t have applied any pattern before, be careful while choosing one of the best practices. Try to answer the question below to define the strategy for your team and environment:

Which is your development methodology?

How flexible is your release? – is the release plan consisting of a set of features defined before starting the work and even the time line for the release? Or, the release is define in a last minute and you have to deliver only the developed features?

How did you process bug fixing? What is the impact of the bug?

How did you handle requirement changes in different development stages before release?

Going through the web and literature one can get confused and don’t know where to start. Choosing one existing branching strategy and pasting into your company might not be the perfect choice. During all the project history we have seen dynamic problems and situations and there is no silver bullet or one key solution. Estimate the technologies and methods applied and start from implementing the most feasible to your team. As you go you will learn to adapt it better to your environment’s needs.

Considering the Microsoft definition of branching and merging [Microsoft2007], and also other best practices we can group different scenarios:

Scenario 1 – No Branches. Your team works only from the main source tree. In this case, you do not create branches and you do not need isolation. This scenario is generally for small or medium size teams that do not require isolation for teams or for features, and do not need the isolation for releases.

Scenario 2 – Branch for Release. Your team creates branches to support an ongoing release. This is the next most common case where you need to create a branch to stabilize for a release. In this case, your team creates a branch before release time to stabilize the release and then merges changes from the release branch back into the main source tree after the software is released.

Scenario 3 – Branch for Maintenance. Your team creates a branch to maintain an old build. In this case, you create a branch for your maintenance efforts, so that you do not destabilize your current production builds. You may or may not merge changes from the maintenance branch back into the main tree. For example, you might work on a quick fix for a subset of customers that you do not want to include in the main build.

Scenario 4 – Branch for Feature. Your team creates branches based on features. In this case, you create a development branch, perform work in the development branch, and then merge back into your main source tree. You can create separate branches for work on specific features to be completed in parallel.

Scenario 5 – Branch for Team. You branch to isolate sub-teams so they can work without being subject to breaking changes, or can work in parallel towards unique milestones. You may encounter one or more of these scenarios. Use these scenarios as a reference point to see what guidance may or may not apply to you.

The table below lists six general topics of software version management deployment, and some coarse-grained best practices within each of those areas. This topic will help to create a common understanding while working with software versioning which happens in a long term during the project life cycle.

 Workspaces 

Where developers build, test, and debug.

Don't share workspaces.

Don't work outside of managed workspaces.

Don't use jello views.

Stay in sync with the codeline.

Check in often.

Use task branching.

Codelines 

Sets of related sources files.

Have a mainline.

Give each codeline a policy.

Give each codeline an owner.

Child codelines 

Variants of the mainline.

Organize child codelines on the tofu scale.

Don't copy when you mean to branch.

Branch on incompatible policy.

Branch late.

Branch, instead of freeze.

Change Propagation 

Moving changes between codelines.

Use the baseline protocol.

Propagate early and often.

Merge down, copy up.

Choose the correct codeline for original changes

Get the right person to do the merge.

Builds 

Turning source files into products.

Source + tools = product.

Version all original source.

Separate built objects from original source.

Use common build environments.

Build often.

Keep build logs and build output.

Process 

The rules for all of the above.

Track change sets.

Track the flow of change.

Distinguish change requests from change sets.

Give everything an owner.

Use living documents.

Learn and use integrations to supporting tools.

Table Refrences [VC]

Note: This paper consider that the reader knows the challenges of creating the product backlog and how to prioritize the main user stories. Although it’s a long and interesting topic, we will not explain how to gather user stories in features and spread them in sprints. I would suggest focusing on Feature Driven Development to gather the main principles of chopping the requirements into small features.

Agile Branching Model

Let’s assume that we have an environment that requires these features: iterations, frequent releases, continuous integration, flexible to requirement changes. We also assume that this example involves only one sprint.

To achieve these features we should design a proper strategy for the team. It is better to use a shared branch for development.

The context of this project is:

After the requirement analysis, we defined 4 features (F1,F2,F3 and F4) for the project.

We prioritized the feature F1>F2>F3=F4

Each time we will make a release to customer's test environment, customer test it and give us the feedback. In next iteration, we release new features, changes and bug fixing of previous features.

When all features are developed, and confirmed by customer, we will make a release to production environment.

Considering the context, we decide to setup the branching strategy shown in the below picture:

Since we have priorities in the feature definitions and uncertain requirements we choose to share the development branch. All the features will be developed in the branch "Development Share Branch A". "Release Branch A" is used for constantly release to customer’s test environment.

Distribute the tasks to be done at Development Branch A. Team starts programming, when development is ready for released create "Release Branch A"

QA start to test the published codelines of F1, and release a bug fixed version of that feature. The error free code is merged into Development Branch A. In the meanwhile, creating of Tag 1.0 is deployed into the testing environment.

Development of feature F2 is in process. But since, F1 is already released the customer may tested and approve or change any of the requirements from F1. This way is an opportunity to catch up misunderstood requirements and prevent directing the development in the wrong path. But it might also be a dead end, as the customer keep changing the requirements. In the last case, we should keep the customer focused to the defined scope and try to control the rest of the planned application development cycle reducing fancy and not important feedbacks.

When F2 is finished, merge the code to the Release Branch A. if during the QA test on Release Branch A, there are no bugs found -> create the new release T1.1 to customer test environment.

While continuing developing F3 and F4, customer can give feedbacks for F1 and F2. When all these tasks are done, merge the code to Release Branch A.

QA testing will define if there is needed further development or release to the test environment. When the feature is bug free, create the release T1.2 to customer test environment.

When customer will approve the content published and created, because he feel confident that the main value of Spint 1 is achieved, merge "Development Branch A" to the trunk, in order to create P1.3. This release will be deployed into Production Environment.

After QA concludes with the final testing on Release Branch P1.3, the new tag P1.3 is created to be released to the Production Environment.

Often there are cases when the customer finds a bug(s) or requires to change one (many) of the requirements. If this new requirement is a must be developed before the other features, there is no escape. Having a flexible model like the one in explanation gives the opportunities to embrace this change without any radical problem. The answer while applying this model will be: There is no issue as we make the changes on the release branch and publish it as soon as possible.

As required above, after F1 is released to the test environment, customer requires a change and need to see it accomplished immediately. The following tasks are accomplished:

The change of F1 will be made at Release Branch A

Adequate testing and merging follows back to Development Branch A. In this instance, a new tag T1.0.1 from Release Brach A to the testing environment.

F2 starts development.

Everyone has encounter situations that customers require something in the last moment. In our case we approve the change by embedding the new requirement in our version control model, as there is room for supporting this kind of habits. While the Production Release is already done and published the client asks a change of requirement.

In this case the Release branch P1.3 is required implanting the following tasks :

When change to codeline is done, merge the change to release branch P.3. QA will follow with testing and ensure a bug free status.

While there is a stable version of the product checking in the code to the trunk should be executed.

In this instance, a new Tag 1.3.1 from release branch P1.3 is ready to released and be merged to the Production Environment.

During the project development lifecycle can be implemented different branching strategies depending on the situation the team is facing.

The Cost of Branching and Merging

Branching and merging are not free operations. There are certain costs to be considered rather than given programming commands or button click to commit the changes. For example, there is the need to change a label on a form, or update an email address for logging purposes. Simple changes such as this may not justify a branch, but there are no hard exceptions for these cases. Any change to the source code has the possibility of creating more work downstream. You can’t look at the source code only, when calculating the cost of working directly in the main code line. There are always other considerations and other possible side effects for the team and it’s processes.

The Mechanical Cost

There is, at minimum, an inherent cost in branching and merging found in the time that it takes to create the branch, switch to the new working branch, merge the branch to its target location and test the merge to ensure nothing broke. This cost is highly variable depending on the source control system that you are using, though.

For example, with Subversion software solutions it only takes a moment to create a branch but it may take many minutes till to a few hours for some repositories over slow connections, to switch the working branch and to do the merge. With distributed versioning systems (DVCS) like Git or Mercurial, though, the cost of branching and merging may be significantly lower. As in fact, the team is never working directly against the master repository or code line.

The Management / Intellectual Cost

The more branching exist in a system, the more management it takes to keep track of them. When sub-branches are arisen, it becomes even more expensive to track them.

Every branch has a source line from where it came. In most cases, this source line will be the target of the merge as well. However, remembering where each branch came in order to merge it back to the correct location can be difficult. Subversion solutions have a commit log that will tell you when and where a branch was made, and there are other tools available that can visualize where the branches came from. Git also has tools to visualize and otherwise represent the branching built right in, such as "gitk". However, these tools don’t come free from intellectual cost.

The Stability and Testing Cost

If testing is done after the software has been built, as a distinct phase before release, then the impact on branching is minimal. Whether or not you branch your code to maintain stability during change, the stability of the system will not be known until after the system has been completely integrated and shipped to the testers. If testing is done as soon as possible, and done manually – that is, tests plans are written and executed by testers that are using the software directly – then the cost of every branch and merge can be enormous.

If testing is done as soon as possible with test automation either immediately after the changes are made – or better yet, with while changes are being made – then the cost of branching can be balanced with the stability of the system with greater ease.

The Cost of Merging Too Much, Too Soon

A branch should be merged when it is "done, done" means that the branch should live independently for as long as it can without impeding the flow of work to the next part of the process. How and when work flows to the next part of the process is a policy that the team decide within the constrains and contexts of the company, customer, and project.

Other Costs and Consideration

There also are many aspects of a system to be considered when branching the code, like a team’s organization, the system’s architecture, etc. Understanding all the options, the context in which team is working, the problems, and the cost of this entire situation will be useful to choose the right option at the right time. Anyhow, the cost against the ROI should not be taken in any consideration while you are making a decision to achieve the team and customer goals.

Conclusions

While team is scaling or releases become very flexible, the common reason for creating a branch is to support parallel development or other activities to improve the process. There is no limit to the number of branches that can be created. However, a branch and merge strategy should be designed prior to creating branches 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. If there is no need to created a branch, save the effort and follow the serial model.

Branching is a very crucial part of software configuration management and choosing the best branching strategy is crucial. If this is properly setup, it will guide you to a successful parallel working, synchronized releases, code integration and testing; also bug fixing. Synchronize very often with the mainline (or trunk) in order to prevent merging errors and having a common codeline within the team. Even considering the cost and other matters, if the context requires branching then there is no other decision to be made.