Updated on December 5, 2023 in #linux

Git Cherry Pick Examples to Apply Hot Fixes and Security Patches

Cherry picking lets you apply 1 or more commits from one branch to another, it shouldn't be abused but it does have its place.

The TL;DR is it lets you copy 1 or more commits from branch A to branch B but using the word “copy” is misleading. It applies the change by creating a new commit for each “copied” commit, you’ll end up with the same 2 commit details in each branch but the “copied” commit will have a different git commit SHA in a similar way that interactive rebasing does.

I very rarely use cherry pick but when I need it, it’s the perfect tool for the job. The reason I don’t use it much is I personally prefer short lived feature branches that get merged into a main branch and that is what gets deployed. This results in performing a lot of small releases frequently and the main branch is always in a deployable state.

I’ve worked with a lot of different companies doing contract work over the years and have seen a bunch of different git branching strategies. This post won’t compare them or pick sides, but I find cherry picking comes up more often with certain strategies.

In this post, we’ll focus on 2 use cases where you might want to consider cherry picking and then we’ll cover how to do it. The commands are the same but it’s often nice to have a concrete example of why you’re running these commands.

# Hot fixes

• You have 2 long lived production and development branches
  • Developers actively commit or merge into development and when releases are ready it gets merged into production

You may want to cherry pick when you encounter a critical bug in production but the development branch isn’t ready to be deployed yet so you can commit the bug fix to development, test it and then cherry pick it to production so you can release the fix ASAP.

# Backporting Security Patches

• You have a long lived main branch but also a maintenance-X branch where X could be a version of your code that you keep around for maintenance or legacy purposes

You may want to cherry pick when you have a security patch that you want to backport out of the main branch into one of your maintenance-X branches. This lets you keep older versions of your software secure without bringing in all of the modern new features.

# When Not to Cherry Pick?

Of course there’s other use cases, but in a lot of cases you might be better off using other commands like reset, rebase or merge.

For example if you accidentally commit a change to your main branch instead of a feature branch that you forgot to checkout then you can do a soft reset on the main branch to undo the last commit with git reset HEAD~.

This will leave your code changes on disk so you can fix the situation by checking out your feature branch and staging + committing your files there. Done!

In my opinion that’s more efficient than cherry picking that commit to your new feature branch and then going back to the main branch and hard resetting the last commit.

Also, if you want to apply all commits from branch A to branch B then using rebase or merge are at your disposal. These will ensure your commits get moved to the branch you’re merging into without making duplicate commits.

# Git Commands

In all cases we’ll be passing in 1 or more git commit SHAs to the git cherry-pick command.

You can find these values by running a git log in whatever branch you want to copy your commit from. We’ll also be running the git cherry-pick command from the branch you want the commit to be copied into.

For example if you want to cherry pick from development to production then you’d run git checkout development and run git log to find the SHA you want to copy, let’s call it abc123 for now. Then you’d run git checkout production and git cherry-pick abc123. Done!

# Cherry pick more than 1 SHA.
#
# This could be useful if you have a handful of commits that you want to bring over,
# you'll likely want to order them with the oldest commit being first in the list.
git cherry-pick <SHA> <SHA>

# Edit the git commit message for the newly applied commit.
#
# This could be useful if want to customize the git commit message with extra context.
git cherry-pick <SHA> --edit

# Avoid automatically creating the commit which lets you edit the files first.
#
# This could be useful if you need to make manual code adjustments before committing,
# such as applying a security patch which uses an older library with a different API.
git cherry-pick <SHA> --no-commit

You can combine these flags as needed. These aren’t all of the flags, but they’re the ones I’ve used the most. You can find the full list in the docs.

The demo video below goes over running these commands and more.

# Demo Video

Timestamps

• 0:30 – Cherry picking frequency may be dependent on your branch strategy
• 2:16 – Applying cherry picked hot fixes
• 4:35 – Being able to modify the git commit message
• 5:44 – Backporting security patches with cherry pick
• 7:34 – Using the no commit flag to modify the cherry picked files
• 9:29 – Cherry picking multiple commits
• 9:57 – When to maybe avoid using cherry pick?
• 12:32 – Do you use cherry pick often?

When was the last time you cherry picked? Let us know below!