Merging code is an important aspect of software development. Here, we break merging code down and deliver some top merge strategies.
Merging Code 101
Merging code allows multiple software developers to integrate changes into their codebase. Developers start this process by branching from a shared codeline, often referred to as a mainline. Then once work the work is completed and tested, the branch is merged back into the codebase.
As teams and projects grow, merging code can become increasingly difficult. Now you have multiple developers working in isolation and trying to merge back changes. This is done to keep the mainline stable.
But most version control systems (VCS) do not keep track of the relationship between branches. Developers need to rely on naming conventions and even additional scripting to know where to merge. This issue becomes even more complex when you have 1,000s of developers all branching and merging at once.
The longer the branches run in isolation, the more complex the eventual merge will be.
To overcome this challenge, developers should merge early and often. This keeps branches up to date with how the main codebase is evolving. It minimizes the likelihood of merge conflicts and keeps developers moving.
Back to topWhy Automate Merges?
Automating merges can also help accelerate development by propagating changes quickly. This helps eliminate bottlenecks. Small changes no longer risk being held up in testing or code review. Now they can be immediately available for other developers.
Automating merges removes the human element out of the resolve process, potentially decreasing errors that can be introduced through requiring only manual merges. Without automation, it’s up to someone in the organization to know where to branch from/to on a continual basis. Human error can result in skipping required merges.
Automated merging works well for changes that do not require either an interactive resolve or advanced integration. One example of an automated merge strategy would be to automatically merge hotfixes from patches into the mainline. By automating this merge, once something is fixed, it is immediately available to teams (once it is built and tested via continuous integration).
Back to topMerge Strategies: When to Automate
It is important to look at defining a pathway for automated merges that is in line with your current branching strategy. Fully automated (unattended) merging works best when focusing on smaller changes. These include bug fixes, but also smaller features.
For example, if you add a button in the GUI or change the color scheme, you probably do not need to go through all the manual steps of a merge. Because these things are easy to test, they can quickly be integrated.
For the automated system to “accept” the change, the merge has to happen without conflict. Then your automated build runner can test the result. Going from stable (released versions) to active development is one good path. In theory, release branches are the most stable. Although, automatic merges can work from anywhere to anywhere if the change is small or isolated.
What to Consider When Merging Code Automatically
Merging code automatically relies on your VCS. This system needs to be able to understand what branches are dependent on each other and your merge strategies. For most systems, this needs to be done using a naming convention.
Figuring out these paths for automating merges is the first step. Then you need to have admins create scripts and triggers. These can be built on top of your VCS but may be costly to maintain. To avoid risks it is important to consider:
- What tag names can you use for branches?
- What merge paths are on isolated branches?
- How can merge paths be enabled/disabled?
- How can developers avoid auto merging particular changes?
- Who should be emailed when automatic merges occur?
- How do you identify and remedy build/test failures?
When to Avoid Auto Merging Code
Focusing automation only on paths likely to produce a good result is one way to help prevent merge automation from leading to chaos. But even when automated merging is helpful, there will still be some merges that just can’t be automated.
For example, an interactive merge is necessary whenever there are conflicting chunks of text modified in the same file in both the source and target branches. Such merges require human interaction to resolve. These should not be automated.
Also, general code cleanup activities are not a good option for automated merging. Keep automated merge destinations to new development branches only and avoid release branches.
In branching strategies where products change extensively on long-lived release branches (as opposed to bugfix-only release branches), the success rate for automatic merges would likely be lower. Automated merging may not be appropriate in that case.
Back to topBetter Merge Strategies with Helix Core
Merging code automatically can be a big lift on your admins, even if it speeds up developers. And depending on your VCS, it may not be possible. But there is an easier way.
Helix Core — version control from Perforce — has Perforce Streams. Merging with Streams is easy because it automatically tracks relationships between branches. Developers are able to see what changes are available, and where their changes should flow.
When it comes to automating code merges, Streams already has defined merge paths that use best practice merge strategies. Using the Stream Graph, you can graphically manage branching relationships. Plus, you can pull everything into your CI pipeline easier to automate the testing. When it comes to advanced merges or conflicts, you can use the Revision Graph or Time-Lapse View to see how the code has evolved over time.
Start merging code without the headache.