What does cherry-picking a commit with Git mean?

Question

Recently, I have been asked to cherry-pick a commit.

So what does cherry-picking a commit in git mean? How do you do it?

Answer 1

This quote is taken from; Version Control with Git (Really great book, I encourage you to buy it if you are interested in git)

Edit: Since this answer is still getting impression, I would like to add very nice in action video tutorial about it:

Youtube: Introduction to Git cherry-pick

Using git cherry-pick The command git cherry-pick commit applies the changes introduced by the named commit on the current branch. It will introduce a new, distinct commit. Strictly speaking, using git cherry-pick doesn’t alter the existing history within a repository; instead, it adds to the history. As with other Git operations that introduce changes via the process of applying a diff, you may need to resolve conflicts to fully apply the changes from the given commit . The command git cherry-pick is typically used to introduce particular commits from one branch within a repository onto a different branch. A common use is to forward- or back-port commits from a maintenance branch to a development branch.

$ git checkout rel_2.3
$ git cherry-pick dev~2 # commit F, above

before:

after:

Answer 2

I prepared step-by-step illustrations what cherry-pick does — and an animation of these illustrations (near the end).

1. Before cherry-picking
   (we are going to do a cherry-pick of the commit L from the branch feature):

---

2. Starting the command git cherry-pick feature~2
   (feature~2 is the 2^nd commit before
   feature, i.e. the commit L):

---

3. After performing the command (git cherry-pick feature~2):

---

The same animated:

---

Note:

The commit L' is from the user's point of view (commit = snapshot) the exact copy of the commit L.

Technically (internally), it's a new, different commit (because e.g. L contains a pointer to K (as its parent), while L' contains a pointer to E).

Answer 3

It will apply a particular commit to your current branch.

This means :

• all files added by this commit will be added
• all files deleted by this commit will be deleted
• all files modified by this commit will be merged. This means the whole file from the commit, not only the changes from this commit!

Ex: Consider commit A

added newFileA
modified main:
+ import './newFileA'

commit B

added newFileB
modified main:
+ import './newFileB'

If you cherry-pick commit B on another branch, you'll end up with :

/newFileB
/main :
   import './newFileA'
   import './newFileB'

since commit B contains newFileB and main, but no newFileA, resulting in a bug, so use with caution.

Answer 4

It's kind of like Copy (from somewhere) and Paste (to somewhere), but for specific commits.

If you want to do a hot fix, for example, then you can use the cherry-pick feature.

Do your cherry-pick in a development branch, and merge that commit to a release branch. Likewise, do a cherry-pick from a release branch to master. Voila

Answer 5

If you want to merge without commit ids you can use this command

git cherry-pick master~2 master~0

The above command will merge last three commits of master from 1 to 3

If you want to do this for single commit just remove last option

git cherry-pick master~2

This way you will merge 3rd commit from the end of master.

Answer 6

Excerpt from the official docs:

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).

When it is not obvious how to apply a change, the following happens:

1. The current branch and HEAD pointer stay at the last commit successfully made.

2. The CHERRY_PICK_HEAD ref is set to point at the commit that introduced the change that is difficult to apply.

3. Paths in which the change applied cleanly are updated both in the index file and in your working tree.

4. For conflicting paths, the index file records up to three versions, as described in the "TRUE MERGE" section of git-merge. The working tree files will include a description of the conflict bracketed by the usual conflict markers <<<<<<< and >>>>>>>.

No other modifications are made.

Read more...