What does cherry-picking a commit with Git mean?

Question

What does git cherry-pick <commit> do?

Instead of merge, with cherry-picking re-committing from a branch to the target branch (ex: master) is easier. — Levent Divilioglu, Jan 09 '16 at 14:29
Could one say?: "Cherry-picking a commit means creating a temporary branch on `HEAD`, merging the diff of that commit into it, then fast-forward `HEAD`." Or in simple words: "*Merging a single commit*". — U. Windl, Apr 15 '21 at 11:53

score 3922 · Accepted Answer · edited May 09 '23 at 08:18

3922

Cherry-picking in Git means choosing a commit from one branch and applying it to another.

This contrasts with other ways such as merge and rebase which normally apply many commits to another branch.

It's also possible to cherry-pick multiple commits but merge is the preferred way over cherry-picking.

Make sure you are on the branch you want to apply the commit to.
```
git switch master
```
Execute the following:
```
git cherry-pick <commit-hash>
```

N.B.:

If you cherry-pick from a public branch, you should consider using
```
git cherry-pick -x <commit-hash>
```
This will generate a standardized commit message. This way, you (and your co-workers) can still keep track of the origin of the commit and may avoid merge conflicts in the future.
If you have notes attached to the commit they do not follow the cherry-pick. To bring them over as well, You have to use:
```
git notes copy <from> <to>
```

Additional links:

edited May 09 '23 at 08:18

Wenfang Du

8,804
9
59
90

answered Feb 18 '12 at 07:29

Philip Fourie

111,587
10
63
83

7

Is cherry picking really necessary? Won't a mixed reset or a soft reset do a similar job? – Nav Jun 06 '14 at 09:13
11

git push is last step to take changes on master – Nagappa L M Apr 03 '17 at 10:30
142

FYI: A commit semantically contains all the files of the working tree of that moment (and the commit hash of the previous commit), so you are not applying a whole commit to another commit, but the changes a commit did on the previous commit `"cherry-pick commit applies the changes introduced by the named commit on the current branch"` Most ppl tend to think of commit as changes (like svn was iirc), but it is not, each commit refers to the complete working tree. Though this doesn't make a difference in this case, it can help in understanding why git works like it does. – Emile Vrijdags Jul 03 '17 at 11:18
3

@Zitrax are notes different from commit message? My single `git cherry-pick` command was able to bring over my commit message as well. Are you talking about something else? I didn't need to run `git notes` command at all to accomplish it. – RBT Aug 15 '17 at 05:09
@RBT Yes notes are different from the commit message, the commit message follows the commit on cherry-pick. See https://git-scm.com/docs/git-notes – Zitrax Aug 15 '17 at 11:04
Nav, the difference would be the same as with rebasing: with cherrypicking you get automerge and don't carry over unwanted stuff from the other branch. – jcanizales Feb 15 '18 at 20:44
do you need to type out the entire commit hash or can you tab complete? – Akin Hwan Jan 17 '19 at 18:19
I think this answer could be improved by showing some example output like "the standardized" commit message. Does that include the original branch name, commit ID and log message? (I haven't cherry-picked yet, but I guess "yes") – U. Windl Apr 15 '21 at 11:44
One thing that isn't noted about git cherry-pick is that file blobs are what are stored in in commits so cherry-pick applies the file blob of that commit to your HEAD. This also means that if changes exist in your file blob that were essentially built upon parent commits, those get implicitly applied too. So its not a patch file that only applies the file changes from parent. – LeanMan Oct 25 '21 at 03:54
3

Purpose of `-x` option: When recording the commit, append a line that says "(cherry picked from commit …)" to the original commit message in order to indicate which commit this change was cherry-picked from. https://git-scm.com/docs/git-cherry-pick – Loner Oct 28 '22 at 12:31
@Nav(readers); no,no,no; A reset removes code, a cherry-pick adds code. No where close to similar goals. – diox8tony Jun 27 '23 at 21:52

score 455 · Answer 2 · edited Oct 18 '21 at 03:20

455

This quote is taken from: Version Control with Git

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, below

before: before

after: after

Also, here is a very nice in action video tutorial about it: Youtube: Introduction to Git cherry-pick

edited Oct 18 '21 at 03:20

Amith

730
6
22

answered May 13 '15 at 15:06

Teoman shipahi

47,454
15
134
158

21

when cherry-picked commits are taken on some branch (b1) and later delivered to master. And if branch b1 (from which commits were originally picked) is also tried to be delivered to master. How about the conflicts? Is that taken care or how does it work? – parasrish Jun 28 '16 at 06:02
7

@parasrish Yes, they are already taken care with your previous merges. So you did changes a,b,c,d from (b1) branch. You cherry picked only "c". Then in future once you merge from (b1) to master, since "c" changes are same, it will only merge a,b,d and remain "c" changes. But if you rollback your merge, then you will go back changes with "c" in it. You will need to roll them back separately. – Teoman shipahi Nov 22 '16 at 16:18
35

It should be emphasized: In the example as given, *only* the difference (F - E) is applied to Z. That is a narrow case. Cherry-pick may be used to apply the differences of multiple commits, say, all of the differences between two non-adjacent commits. For example, following from above, (F - E), (E - D), (D - C), and (C - B). That is equivalent to applying the difference (F - B). – Thomas Bitonti Jul 25 '17 at 21:28
2

Also, what happens if the selected Commit (F in the example) has more than one immediate predecessor? – Thomas Bitonti Jul 25 '17 at 21:29
2

@ThomasBitonti I think it is pretty clear only the difference (F - E) is applied to Z. Letters indicate commits, and single commit applied over Z. You can clearly see it in the command as well. Also OP asked for "What is cherry picking", not how to apply "Multiple Cherry Picks". Moreover applying cherry pick from single commit is not a narrow case, it is pretty much a wide case scenario. – Teoman shipahi Jul 25 '17 at 21:35
1

I'm confused by what the ~2, the #, and the ", above" accomplish in the example; any explanation? – TahoeWolverine Jul 31 '17 at 15:46
@Teoman shipahi so what i was thinking of doing is using git cherry-pick instead of git merge when i have finished a feature and want to merge it into my master branch. so anytime i do a feature and its 100% complete,i'd like to do git cherry-pick with the last commit hash instead of git merge or git rebase, what are your thoughts on this ? why dont more people do this after a feature is complete ? – j2emanue May 14 '18 at 12:49
1

@j2emanue I think you should definitely do git merge, instead of git cherry-pick in your case. Then you will get full benefit of keep tracking of history, and git branching ideology. git cherry-pick should be used in very rare cases, like you created a branch, then changed 10 different files just for testing a feature, and just changes in only one of the files (or full commit depending on the what you commit) makes sense. So instead of merge, you can cherry pick that file. Otherwise, for adding feature or bug fixes, branching and merging is way to go. – Teoman shipahi May 14 '18 at 14:23
4

@j2emanue in other words, cherry-pick will only take changes of last-commit. If you commit 3 different times, and if you cherry pick last one, it will not take changes on first and second commit. Merge command will take all your changes and apply to your target (master) branch. – Teoman shipahi May 14 '18 at 14:26
1

This seems like a very good answer. Would you mind editing your answer and reply to tahoewolverine's comment about what `cherry-pick dev~2 # commit F, above` does? The answer is made complex for one who's coming to learn _one_ git command and now he's introduced with 2 more command/options to learn of – mfaani Oct 26 '18 at 14:37
1

Cherry-picking _does not_ apply just the changes from a single commit (E-F) to Z. It applies changes (E-F) to Y-(E-Y)-Z. I haven't yet found a workaround to this frustrating behavior. – Suncat2000 Apr 02 '19 at 14:00
As I mentioned in my reply above, beware: cherry-picking will not apply the _changes_ (as in : the lines of code which have changed) but the _commit_ (meaning the _whole_ files which have changed) – mandelf Jan 05 '21 at 16:22

score 204 · Answer 3 · edited Jan 14 '16 at 10:41

204

Cherry picking in Git is designed to apply some commit from one branch into another branch. It can be done if you eg. made a mistake and committed a change into wrong branch, but do not want to merge the whole branch. You can just eg. revert the commit and cherry-pick it on another branch.

To use it, you just need git cherry-pick hash, where hash is a commit hash from other branch.

For full procedure see: http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html

edited Jan 14 '16 at 10:41

Aurelio

24,702
9
60
63

answered Feb 18 '12 at 07:29

Tadeck

132,510
28
152
198

What happens if the underlying branch changed, such that the cherry pick doesn't make sense? – information_interchange Feb 11 '22 at 19:24

score 140 · Answer 4 · edited Jul 05 '23 at 17:10

140

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

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

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

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

edited Jul 05 '23 at 17:10

Slate

221
5
14

answered Sep 17 '19 at 02:04

MarianD

13,096
12
42
54

Does it mean, L' will be N -> M -> L on branch master? or it will exclusively bring commit L on master branch – Priyank Thakkar Apr 22 '20 at 02:13
4

@PriyankThakkar, yes, **exclusively L**, nothing else (as you can see from pictures / animation). – MarianD Apr 22 '20 at 10:45
2

»The commit `L'` is from the user's point of view (commit = snapshot) the exact copy of the commit `L`.« – No, it's not the same snapshot (unless the snapshots K and E were already the same), just the same difference (i.e. E→L' = K→L). – Paŭlo Ebermann Nov 30 '20 at 20:05
@Paŭlo, you extracted this sentence out of context, not reading just the next one...:-) Moreover, the differences E→L' and K→L are **not** the same. – MarianD Dec 01 '20 at 09:06
Yeah, but the changes in K is also applied right.? – Jovylle Feb 07 '21 at 10:21
@Jovylle, think about a commit as a **snapshot**, not as differences between them. *Differences git don't save,* only the current full content of files. So changes from **K** to **L** don't matter, only the current status of **L**. – MarianD Feb 07 '21 at 19:04

Daniel Perník · Answer 5 · 2019-03-28T14:59:22.280

121

Short example of situation, when you need cherry pick

Consider following scenario. You have two branches.

a) release1 - This branch is going to your customer, but there are still some bugs to be fixed.

b) master - Classic master branch, where you can for example add functionality for release2.

NOW: You fix something in release1. Of course you need this fix also in master. And that is a typical use-case for cherry picking. So cherry pick in this scenario means that you take a commit from release1 branch and include it into the master branch.

edited Mar 28 '19 at 14:59

answered Dec 11 '18 at 13:00

Daniel Perník

5,464
2
38
46

21

You might just need the other way. You fixed a bug in master and you should cherry-pick that to release1. Also they might be repositories rather than branches – canbax Jul 22 '19 at 11:03
7

Why do not use merge for it? – FreeLightman Feb 02 '20 at 07:42
3

I would: create branch off release, fix it in the branch, merge branch in release, merge release in master. – Jasper-M Mar 11 '20 at 15:22
I think this answer requires to explain the relationship between branches: If `release1` is expected to be merged into `master` later, it might not make sense to cherry-pick (IMHO). You would also want to rebase `master1` after having cherry-picked, I guess. – U. Windl Apr 15 '21 at 11:48

score 76 · Answer 6 · edited May 09 '18 at 00:48

cherry-pick is a Git feature. If someone wants to Commit specific commits in one branch to a target branch, then cherry-pick is used.
git cherry-pick steps are as below.

checkout (switch to) target branch.

git cherry-pick <commit id>

Here commit id is activity id of another branch.Eg.

git cherry-pick 9772dd546a3609b06f84b680340fb84c5463264f

push to target branch

Visit https://git-scm.com/docs/git-cherry-pick

score 28 · Answer 7 · edited Apr 11 '18 at 22:00

28

You can think if a cherry pick as similar to a rebase, or rather it's managed like a rebase. By this, I mean that it takes an existing commit and regenerates it taking, as the starting point, the head of the branch you're currently on.

A rebase takes a commit that had a parent X and regenerates the commit as if it actually had a parent Y, and this is precisely what a cherry-pick does.

Cherry pick is more about how you select the commits. With pull (rebase), git implicitly regenerates your local commits on top of what's pulled to your branch, but with cherry-pick you explicitly choose some commit(s), and implicitly regenerate it (them) on top of your current branch.

So the way you do it differs, but under the hood they are very similar operations - the regeneration of commits.

edited Apr 11 '18 at 22:00

SherylHohman

16,580
17
88
94

answered Jan 31 '17 at 22:19

Hugh

748
9
9

1

I find this to be a quite helpful view of things. It implies why `cherry-pick` behaves the way it does when the target branch is later merged back into the source branch. Thank you, sir. – Aluan Haddad Jul 10 '17 at 14:09
3

i would like to use cherry pick instead of git merge after a feature is done. everyone always does git merge feature_branch when they are completed a feature. why not use cherry-pick command ? do you have any thoughts ?why bother squashing commits if i can cherry-pick – j2emanue May 14 '18 at 12:51
1

You could see a rebase as a combination of reset and cherry-pick. – Paŭlo Ebermann Nov 30 '20 at 20:07
1

@j2emanue Compared to a real merge, cherry-pick will flatten the history, which can give you non-compiling code in the middle if you don't pay attention. Compared to a squash merge, it's more difficult to use because you need to pay attention to take all commits with you. – Paŭlo Ebermann Nov 30 '20 at 20:11

score 25 · Answer 8 · answered Nov 12 '19 at 15:56

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.

Certainly the most interesting answer, because it talks about what is important, the files, not the commit as a whole. — mins, Jun 08 '20 at 23:53
This needs more consideration, the result of cherry pick can lead to dangerous paths ^^ — Burgito, Jan 04 '21 at 14:52

score 17 · Answer 9 · edited Apr 11 '18 at 21:54

17

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

edited Apr 11 '18 at 21:54

SherylHohman

16,580
17
88
94

answered Oct 07 '16 at 11:55

Ajeet Sharma

214
2
9

score 13 · Answer 10 · answered Jan 21 '19 at 08:30

When you are working with a team of developers on a project, managing the changes between a number of git branches can become a complex task. Sometimes you don't want to merge a whole branch into another, and only need to pick one or two specific commits. This process is called 'cherry picking'.

Found a great article on cherry picking, check it out for in-depth details: https://www.previousnext.com.au/blog/intro-cherry-picking-git

score 12 · Answer 11 · answered Mar 19 '19 at 12:38

12

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.

answered Mar 19 '19 at 12:38

Bilal Saidumarov

169
1
4

This is confusing. I think here you're on a branch other than master, right? And when you mentioned two commits you're referring to the and commits to define the range you want to cherry-pick. Correct? It would greatly help if the scenario is described. Good addition though. Thanks. – Saurabh Patil Jul 31 '19 at 07:19

Shubham Verma · Answer 12 · 2023-03-02T04:25:35.147

Here you can perform the cherry pick step by step

Pick only specific commit(s) and raise PR for only those changes:

Step 1: Select those commit hash (Click on commit id and get the complete hash):

https://bitbucket.org/project-name/repo-name/commits/52597fbcc7010e3d4e1ccbdeb5b325331bd3c26

In the above URL, commit hash is: 52597fbcc7010e3d4e1ccbdeb5b325331bd3c26

Step 2: Collect all commit hash that need to have in PR, Suppose, I need 3 commits and its code to have in master and I need raise the PR:

https://bitbucket.org/project-name/repo-name/commits/52597fbcc7010e3d4e1ccbdeb5b32

https://bitbucket.org/project-name/repo-name/commits/ed0e2169ca0f2c69687999977773cc100938185

https://bitbucket.org/project-name/repo-name/commits/5e770f730bacb9ee6e4804b5e66df90b6493139

Step 3: Go to the Repo and run following commands:

git stash
git checkout master
git pull origin master
git checkout -b "my-new-branch"
git cherry-pick 52597fbcc7010e3d4e1ccbdeb5b325331bd3c26
git cherry-pick ed0e2169ca0f2c69687999977773cc100938185
git cherry-pick 5e770f730bacb9ee6e4804b5e66df90b6493139

git push origin my-new-branch

Step 4: Raise the PR against master

score 1 · Answer 13 · answered Mar 21 '20 at 08:01

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:

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

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

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

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.

What does cherry-picking a commit with Git mean?

14 Answers14

Linked

Related