So, I have a maintenance branch and a master branch in my project. If I make a commit in the maintenance branch and want to merge it forward to the master branch, that\'s ea
Alternate solution to using "git cherry-pick
" (as recommended in other responses) would be to create a separate [topic] branch for the fix off maintenance branch, and merge this branch first into maintenance branch, then into master branch (trunk).
This workflow is (somewhat) described in Resolving conflicts/dependencies between topic branches early blog post by Junio C Hamano, git maintainer.
Cherry-picking results in duplicated commit, which down the line may cause problems when merging or rebasing. Topic-branch based workflow keeps only one copy of the fix.
For complex commits that cannot be applied using git cherry-pick you can try
git checkout -b merge-branch master
git rebase --onto=`git merge-base master maintenance` HEAD~1 && git rebase master
Explained: http://blog.boombatower.com/automatically-backport-commits-using-git.
Yes, it is considered cherry-picking and no, generally it should not introduce problems. If commit doesn't apply cleanly when backporting you may face exactly same conflict when cherry-picking it back.
This is exactly the use case for git-cherry-pick
git checkout maintenance
git cherry-pick <commit from master>
As a general rule, I use merge to move changes "up" the tree (from maintenance to master) and rebase to move them "down" the tree (from master to maintenance). This is so the order of commits in the master branch is maintained.
Rebase essentially rolls back all your changes on the current branch to the fork (or last rebase), copies over newer changes and then re-applies your changes.
If you don't want to get all changes from the master, then you will probably need to cherry pick the ones you want.