Sometimes you just want a few patches from a topic branch, not the entire thing. If a bug fix was implemented that would help everyone working out of the master branch, but the rest of the topic branch isn’t acceptable, git cherry-pick is the way to go.
The basic usage for git cherry-pick is git cherry-pick <commit>. This will apply <commit> on top of your current branch.
git cherry-pick has some useful options:
-e|--edit-x-n|--no-commit-m <parent-number>
-e lets you edit the commit message before the patch is commited.
-x adds a note to the commit message explaining where it came from originally. This is helpful if you’re backporting a feature or fix from one branch to another.
-n applies the changes but doesn’t actually create a commit. This can be really helpful if you’re combining multiple commits from different places (it can be simpler than using git rebase).
-m <parent-number> lets you cherry pick from a merge. If you tell git cherry-pick which parent is the “mainline”, it can calculate the commit’s impact (its diff) relative to the mainline and apply that as a patch against your current branch.
References:
git-fu 
2 comments
Comments feed for this article
November 26, 2008 at 2:07 am
Mark Stosberg
It’s not clear how parent-number is calculated.
November 27, 2008 at 6:12 pm
xentac
It’s not all that clear, it’s true. Git has an internal representation for the ordering of the parents. In the case of a two branch merge, the branch you merge into is parent 1 and the branch you merge from is parent 2.
In octopus merges the branches are ordered based on the order you put them in the merge command.
That being said, most visualization clients (tig, qgit, etc) show the parent commits in order.