cherry pick

in Development

Are You Using Cherry Picking to Save You Time?

cherry pick

You’re working in Git, developing something with your software development team. Let’s say you have 2 branches: master and production. At some point, there was a change in the master that fixed a bug that existed, but it’s buried in the 20 most-recent commits since the last merge to production. Since the master branch is the one all of the developers on your team work out of, it’s not always in a “production-ready” state. So – of the last 20 commits, there is one you need to copy to the production branch to fix a bug, and 19 that aren’t ready for production. How do you single out that one commit?

Enter Cherry Picking

With the use of git cherry-pick, you can merge only the changes that include the bug fix from that single commit into the prod branch, without taking the changes from the other 19 non-production-ready commits. In a different scenario, this could be done in reverse, where a fix is done only in the production branch, but it needs to be merged back into the master branch.

Similarly, if you’re working with open-source projects on GitHub, you might see someone else fix a bug (or do anything you like, for that matter). You could cherry-pick from one project to another. Pretty handy, right?

How Do You Use It?

Git explains their cherry-pick command on their site. The definition is simply:

“Given one or more existing commits, apply the change each one introduces, recording a new commit for each.”

From there, they break down options to use the command in various ways. For example, you could use git cherry-pick -x to indicate which commit the change was cherry picked from. This is an important one because the commit hash will change when you cherry-pick it. If you need to know where it came from, this will insert a commit message noting where it came from.

If Git’s page is a bit mind-boggling to start, go to the appropriately named Think Like (a) Git: A Guide for the Perplexed for a great visualization of the process (including helpful slides at the bottom). AlBlue’s Blog has some great tips as well.

Essentially, all you need to do is go to your target branch and grab the commit hash code for the commit you want to copy. Run the cherry-pick command with the hash code and that’s it!

Cherry Picking Sounds Great. You Should Use It All The Time, Right?

Remember, when you cherry-pick a command, it will record a new commit with a new hash. Git isn’t going to recognize your new commit as the same thing as the original. If you’re going to merge your changes when you’re finished, you’re going to have to resolve any conflicts that will occur because of the new commit you created with cherry-pick.

In some cases it won’t be difficult to resolve conflicts, but other times it will be more headache than it’s worth. On a helpful found drama blog post about cherry picking, the author points out that cherry picking is best used when you don’t need to integrate your topic branch back into the master. Sometimes you might want to use a different method to fix problems that will merge more smoothly.

Cherry picking is a useful tool to have in your toolbox, but you have to keep in mind what effect it will have. Use it carefully and it will be a great help.

Cherry Picking photo courtesy of