Backporting Code to Support Branch

Fix the bug on master, test it, commit and push as usual

To check out the branch as local tracking branch (only needs to be done once):

or just switch to the branch and make sure it is up-to-date

Cherrypick the commit from the master to the support branch.

Use the commit ID from the master branch as argument. Repeat this if more commits needs to be backported. Mare sure you maintain correct ordering of the cherrypicking. Also have a close look at the commit messages and/or patches of the commits that you are cherrypicking. The code cherrypicked from master may depend on some previous work done on master that was not cherrypicked to support branch yet. In such case these commits needs to be taken to support branch as well. Alternatively a cherrypick gone bad may be manually fixed with a direct commit to the support branch.

You may get conflicts during the cherry-pick. The git status command will show the conflicts. The same command will also tell you how to fix them: just open the conflicting files, find where the conflict occured and modify the file to the correct version. The use git add to mark the conflict fixed. Do this for all the conflicting files. Then continue the cherry-pick with: git cherry-pick --continue

Please note that the cherrypick is different from a merge. Cherrypick creates new commits (also see reasoning below).

Make sure that the cherrypick went OK by building the branch and runnig (at least some) tests.

Then push the changes to the server:

After the push please make sure everything works by checking the state of MID-SUPPORT plan on Bamboo

We want to have mostly linear development because we want to integrate the code continually. All the time. We avoid branching. There are git-based models that use a lot of branching and merging (such as http://nvie.com/posts/a-successful-git-branching-model/). We don’t like these models for midpoint core team. The core team is small and works well together. Although we use some topic branches we otherwise try to keep things simple and avoid branching.

Our focus is on the development of next midpoint version which happens on master. All bugfixes usually go there. Backporting a fix mostly an exception. When we create a fix we do not know whether it will need to be backported later or not. Therefore we do the easiest thing which is also a common case: fix on master. If the fix needs to be backported then just cherrypick it to support branch. Cherrypick creates new commit and efficiently breaks merging. But that’s not a problem. We do not expect that we will ever merge support branch back to master.