By Thomas Behlau
The Atlassian tools Stash and Bamboo allow users to configure auto-merging of source code. In my next two blogs I will give some details about this feature and discuss some pitfalls. For this demonstration I used the 3.1.3 version of Stash.
The configuration of the auto-merge feature in Stash is as easy as it gets. Go to the Settings page of your Stash repository and click on the 'Branching Model' setting. You will find the auto-merge setting on the bottom of the page.
As you can see, the settings are straightforward. There are two things to remember. First, only branches that are prefixed with the Release branch name (in this demo 'release') will take part in the auto-merge. And second, auto-merge will only kick in if the code is pushed into one of the release branches using a Pull request. A simple commit will not do it!.
For this demo we set up three release branches: v_1.0, v_1.1, and v_1.2.
Testing the Auto-Merge
Let's start with a very simple example. In the first case we checked out the develop branch, changed a few files, committed and pushed the changes back to repository. After creating a Pull request from branch develop to release/v_1.0 we attempt to merge the changes and see the following dialog:
In the second example we did a very similar change. First we created a bugfix branch off release/v_1.1, made some changes, committed and pushed the changes back to the Stash sever. This time we merged the changes into the branch release/v_1.1. As you can see in the picture below, Stash realizes that only releases starting from v_1.1 should be involved in the merge and applies the Pull request accordingly.
So far we have looked at examples of auto-merging which did not cause any problems. But what happens if Git detects a merge conflict? Actually, Stash will try to execute the merge down the list of releases until it detects a merge conflict. At this point Stash stops. For the convenience of the user Stash will create a new Pull request automatically from the last successfully merged version to the next version. In the next picture you can see how a new pull request from release/v_1.0 to release/v_1.1 was created.
Now it is time for the user to solve the conflict. The auto-merge process will then continue and ripple its way down the release branches.
The trickiest part actually comes from the way Atlassian parses the versions. If you stick with the pattern that I used in the draft you will be fine. Atlassian uses semantic versioning (http://semver.org/). So if you use something fancy, like city names for versions (Atlanta, Boston, Cleveland,...), read the Branch Ordering Algorithm and write some testing to check if Atlassian's ordering matches your expectation.
You have seen a quick example in the world of Stash auto-merging. Taking a closer look at this feature can help your development team to streamline the release process... and save you from a lot of manual merging. In the next part of this series, we will analyze the auto-merge features that are available in Bamboo.