-
Notifications
You must be signed in to change notification settings - Fork 0
Working with Git branches
When you’re fixing a bug, the first thing to do is to decide where the fix needs to be made. Typically, the fix will be applied to the earliest-affected maintenance branch. However, if the fix is considered high risk, then it may be appropriate to only make the change in master.
If you’re fixing an issue in 1.2.x the rough sequence of commands would be:
$ git checkout 1.2.x $ git pull
Make your changes
$ git add $ git commit $ git checkout master $ git pull $ git merge --no-ff 1.2.x $ git push
If a change has already been made on master and that change is now also wanted in a maintenance branch then you can back port it using cherry-pick
$ git checkout 1.2.x $ git pull $ git cherry-pick <SHA> $ git checkout master $ git pull $ git merge --no-ff 1.2.x $ git push
Note: This should rarely be necessary. Wherever possible changes should be made in a maintenance branch and merged forwards.
When you’re making a change in multiple branches, conflicts may occur. The best person to address the conflicts is the person who made the original change and the best time to do it is straight after the original change was made when things are still fresh in the mind. If you make a change in a maintenance branch and then don’t merge it forwards, you’re leaving the next person who makes a change in that branch to deal with any conflicts in your changes.
The problem with cherry-picking is that you end up with two different commits with different SHAs for what should have been the same change. That doesn’t happen when you merge forwards. Having a single commit for a change is important as it allows Git’s standard tools to be used to, for example, find out which branches contain a change.
A change that was made in 1.1.x and then merged forwards:
$ git branch --contains 7945b29669869f79b66b67dad420d7d9d0abb3ec
1.1.x
master
Versus one that was back ported using cherry-pick
$ git branch --contains 13ee41d04d10e8e66a503dbd69b77858ee8264c2
master
You may have arrived at the commit SHA using a tool like git bisect. In the latter case, you now have to rely on some other mechanism (such as looking for a common subject line) to find out if the commit’s in any other branches.
Why cherry-picking should not be part of a normal Git workflow provides some further reading, although it is rather hyperbolic.