Best practice to commit a bug fix into both master and branch
If a fix needs to be committed into both master and another branch (on an remote shared repo), what is the best practice?
Since we cannot use git merge here because not all the commits in master or branch should go into another, is cherry-pick the best choice?
commit FIX to master
cherry-pick FIX from master and push
Does cherry-pick have the same issue as rebase (never rebase if the commit is going to be shared) ?
4 Solutions collect form web for “Best practice to commit a bug fix into both master and branch”
cherry-pick is a good choice in your case!
Does cherry-pick have the same issue as rebase (never rebase if the
commit is going to be shared) ?
Cherry-pick has no any issues, like
rebase, because it works in way: read difference for the commit you are cherry-picking and apply the patch to the
branch. This does not destroy history (like
rebase). After the operation these commits will not be coupled in any way!
The preferred practice should be to make the fix on a branch that is the common base of all the branches where the fix should be merged to, and merge that commit into all the target branches. This allows you to have a correspondence between “is commit A in branch B” and “is the fix for bug A in branch B”.
If you don’t have such a branch naturally, you can make a temporary one from a suitable point in history, e.g. found using
Circumstances where this may prove problematic is where the branches have diverged so much that essentially you need to make a difference fix to solve the same problem in each branch.
git checkout -b quickfix $(git merge-base master branch) # Note, you may want to check 'git merge-base -a' and choose the best one # code, code code git add <modified files> git commit -m "Fix for pressing issue" git checkout master git merge quickfix # Review merge and test result, fixup merge if necessary git checkout branch git merge quickfix # Review merge and test result, fixup merge if necessary # Optionally, push all branches to 'origin' git push origin branch master
Cherry pick is the right choice.
Commit to master, and cherry pick the commit onto your branch as well.
I don’t understand your comparison with
rebase, but note that cherry pick creates a completely new commit ( of course, because the parent and other meta data are going to be different )
If you ruled out merge indeed cherry-pick is left as the only option. First push the master, then pick to branch using the form that adds hash of original to the commit message.
The problem with picks is that they create a new commit and that makes it damn hard to know what is contained where really. So try to preserve as much relation info as you can.