The cherry-pick
takes as arguments a list of commit identifiers.
That is, it is used as follows:
git cherry-pick commit1 commit2 ...
With this, it will pick up the difference that each of these commits introduced (can be seen with git show commitX
) and apply in position (HEAD
) in which you are.
So, some important conclusions:
- This command creates no connection to the original branch you brought the commit from. The only connection that exists is in the commit message, which is only meaningful to the user who reads it (git does not use this information).
- git will not be able to identify that these differences have already been applied at a future time. I’ll take an example below.
- If you spin
git cherry-pick branchB
, he only will bring the last branch modification B. After all, Branch B
is an identifier for the most recent commit in this branch.
Now, comparing it to git merge
... Let’s assume the following commit history:
Branch A
|
1--2--3--4
|
5--6--7
|
Branch B
If you’re in the branch A
, and rotate the command git merge B
, the following steps will occur:
- git will find the first common ancestor of the two branches. In this case it is the commit
2
.
- He will check the difference between
2
and 4
, and compare with the difference between 2
and 7
. This comparison will dictate the application of the merge.
- That is, at the end of the merge, in the
branch A
all amendments to the branch B
from its first common ancestor (Commits 5
, 6
and 7
).
- This merge information is also saved. That is, if you in a future attempt to merge
branch B
with the branch A
for the second time, it will not apply these modifications again. This is very important when it comes to a larger number of branchs
or one of a more complex workflow.
- Another example: If in your original branch you haven’t had any commits since the branch you’re bringing in the merge (i.e., there was no fork), git will be smart and simply "point" the A branch to the end of branch B (
Fast-Forward
). Cherry-pick would duplicate all commits from one branch to the other without need.
Briefly we see that the differences are:
- The
merge
takes into account (and stores) more information when merging than a simple Cherry-pick.
- The
merge
will bring all differences from the first common ancestor, while the cherry-pick
will bring only the differences of the specified commits.
- The
cherry-pick
is useful, for example when you have a commit that is in the middle of another branch (for example, in the above drawing commit 6
), and you want to bring only him, without bringing the rest of the branch or worrying about the conflicts that it can generate. This should be done carefully, because if in the future you try to merge the branch, git won’t know that an intermediate commit has already been taken into account.