Skip to main content

Intro to Cherry Picking with Git

When you are working with a team of developers on a medium to large sized 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'.

by pasan.gamage /

When should we use Cherry Picking?

I will try to explaining this through a scenario which will make it easier to understand.

Let’s say you are working in an project where you are making changes in a branch called new-features. You have already made a few commits but want to move just one of them into the master branch.

  • From new-features branch run git log --oneline  to get a better log of your commits history. Note that the commit hash is what we need to start the cherry picking. For example:
Git log output
  • Checkout the branch where you want to cherry pick the specific commits. In this case master branch:

git checkout master

  • Now we can cherry pick from new-features branch:

git cherry-pick d467740

This will cherry pick the commit with hash d467740 and add it as a new commit on the master branch. Note: it will have a new (and different) commit ID in the master branch.

If you want to cherry pick more than one commit in one go, you can add their commit IDs separated by a space:

git cherry-pick d467740 de906d4

  • If the cherry picking gets halted because of conflicts, resolve them and

git cherry-pick --continue

  • If you want to bail of this step out altogether, just type:

git cherry-pick --abort

After all this is done, you can simply push the new commits to the upstream repo (e.g origin) and get on with your day.

Tips n Tricks

In case you needed to cherry pick a merge instead of a commit, you can use:

git cherry-pick -m 1 <hash>

Caution!

Cherry picking is commonly discouraged in developer community. The main reason is because it creates a duplicate commit with the same changes and you lose the ability to track the history of the original commit. If you can merge, then you should use that instead of cherry picking. Use it with caution!

Further Reading

Here is some good material for broadening your knowledge:

  1. https://www.devroom.io/2010/06/10/cherry-picking-specific-commits-from-another-branch/

  2. http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html

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

Tagged

Git