git - cherry-pick - HOWTO / WHYTO
Problem: You want to test a feature someone has developed, but it only exists in a remote branch which is woefully out of date.
Source
- How does cherry-pick solve the problem?
- Why won't I use git am or git apply?
Problem: You want to test a feature someone has developed, but it only exists in a remote branch which is woefully out of date.
If you merged or rebased, you'd get a bunch of old changes in, possibly conflicting.
With cherry picking, you take one change set, and replay that as a new commit over another branch.
This is useful if you just want one commit onto another branch, without its history.
It's useful to use the -x option, so the commit message contains a note where it was cherry picked from.
Why won't I use git am or git apply?
because git apply is for applying patches (files), and git am for applying series of patches. git cherry-pick applies commits - i.e., commits from your own repo, vs commits you import from other repos.
From git help cherry-pick:
git-cherry-pick - Apply the changes introduced by some existing commits
[...]
Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).
So, when you cherry-pick a commit, git takes that commit's changes (its diff) and tries to apply it on your current working directory, creating a new commit that is equivalent to the one you are cherry-picking.
It's a way to re-do another commit's changes on a different history line.
Besides taking the changes, cherry-pick also preserves the original commit's info like author and that.
Lastly, cherry-pick can receive a group of commits to apply, in which case it would act like cherry-picking them one by one, in chronological order (older first).
Problem:
You want to test a feature someone has developed, but it only exists in a remote branch which is woefully out of date.
It solves the problem because:
- you don't want to merge the old branch including commits which are no longer relevant in your current state of development
- you don't want to rebase your branch on top of an old branch just to get that one commit.
- you won't have to merge back your branch to that old branch
The last point is important because the first drawback of cherry-picking is that it introduces duplicate commits. But in your case, it doesn't matter.
The other drawback is that the commit you are cherry-picking might have functional dependencies based on previous commits (of that old branch).
In other word, its code works only because of other codes of other older commits (which aren't cherry-picked).
That can be trickier to detect.