5 Ways Git Cherry-Pick Can Boost Your Efficiency And Make You A Better Software Developer

Getting More Out of Git: How Cherry-Pick Can Help You Work Smarter, Not Harder As A Software Developer

Corey Duffy
Level Up Coding

--

Work smarter, not harder.

As a software developer, you’re likely under pressure to get things done quickly and efficiently. One powerful, but often overlooked, tool that can help with this is git cherry-pick. When used correctly, this command makes it extremely easy to manage changes, collaborate with your team and get things done quickly.

For this reason, git cherry-pick is one of my personal favourite git commands. Let’s take a look at how to use it effectively.

The mascot for GitHub
Photo by Roman Synkevych 🇺🇦 on Unsplash

What Is Git Cherry-Pick?

In short, git cherry-pick is a command that allows you to apply a specific commit from one branch to another. For example:

“I want to apply commit 1234 from the feature1 branch to the main branch”

or

“I want to apply commits 1234 to 4567 from the feature1 branch to the main branch”.

We can achieve these outcomes by using git cherry-pick like so:

# Apply commit 1234
git cherry-pick 1234

# Apply commit 1234 and commit 2345
git cherry-pick 1234 2345

# Apply commits 1234 up to 4567
git cherry-pick 1234..4567

This is useful when you want to merge changes from a single commit or range of commits from one branch to another, rather than merging the entire branch.

So, how can you make the most out of git cherry-pick?

Here are 5 ways in which you can use this command to improve your effectiveness as a software developer:

1. Apply Hotfixes Quickly and Easily

There’s nothing worse then the feeling of pure dread when you find out that something is broken in your production environment.

Luckily, git cherry-pick can be incredibly helpful when it comes to managing hotfixes.

For example, let’s say you are working on a project with a team of developers, and one of your team members accidentally introduces a bug into the codebase that causes issues in production. You’ll need to fix this bug quickly before it affects your users and end up with managers breathing down your neck.

Luckily, you know that this bug has been fixed on your main feature branch. However, you don’t want to merge the entire feature branch into your main branch just yet. So, what you do you?

Well, you can use cherry-pick to apply only the specific commit that resolves the issue to a new hotfix branch, which can then be deployed without including any other changes that may not be ready for production yet.

Here’s an example of how you could use cherry-pick to apply a hotfix:

Create a new branch for the hotfix:

git checkout -b hotfix

Find the commit that resolves the issue you’re trying to fix on your feature branch:

git checkout feature
git log
# From the git log we see that we need commit abc123

Cherry-pick the commit to your hotfix branch:

git checkout hotfix
git cherry-pick abc123

Push the hotfix branch:

git push origin hotfix

From here you can easily create a pull request with the hotfix branch to master, or you can deploy the hotfix branch directly if that’s better suited to your workflow.

With cherry-pick, applying hotfixes becomes quick and easy, saving you time and ensuring that issues are resolved as soon as possible.

2. Backport Changes to Older Branches

cherry-pick is the perfect command for applying a specific change to an older or different branch.

For instance, imagine that you have a project with a main branch and a feature branch. You have made some changes to the feature branch, but you also need to apply only some of these changes to the master branch. Instead of merging the entire feature branch, you can cherry-pick the specific commit that contains the changes you want to apply and then merge it into the main branch.

This can be useful when you want to avoid merging an entire feature branch, which may include other changes that are not ready for production yet. For example:

git checkout main
git cherry-pick 1234

In this example, we’re checking out the master branch and then cherry-picking the commit with the commit id of1234. This will apply any changes from that commit to the main branch, without needing to merge our feature branch.

3. Reorder Your Commit History

Sometimes, you may end up committing changes in the wrong order, or you may later realise that if you rearranged your commit history, your changes would be a lot easier to understand.

For example, let’s say that you are working on a feature that involves multiple commits, but you’ve accidentally committed a bug fix before completing the main feature that you’re working on.

In this case, you may want to reorder the commits so that the bug fix commit comes after the feature commits. This way, it’s easier to understand the order in which the changes were made and what specific changes were included in each commit.

To reorder commits using cherry-pick, you can use the --no-commit option.

When you use the --no-commit option with git cherry-pick, Git will apply the changes from the specified commit(s) to your working directory, but it won't automatically create a new commit. This allows you to make additional changes or modifications to the code before committing the cherry-picked changes.

Note that you can also use -n as a short-hand for — no-commit. e.g. git cherry-pick --no-commit and git cherry-pick -n will perform the same operation.

You can then use git commit --amend to create a new commit that includes the desired changes in the desired order.

Here's an example:

# Assume we have the following commit history:
# Commit 1: Add feature A
# Commit 2: Fix bug X
# Commit 3: Add feature B

# To reorder commits 2 and 3:
git cherry-pick --no-commit 3
git cherry-pick 2
git commit --amend -m "Add feature B, fix bug X"

# The new commit history will be:
# Commit 1: Add feature A
# Commit 2: Add feature B, fix bug X

By using cherry-pick to reorder your commits, you can keep your commit history clear and organised, making it easier to collaborate with others and maintain your codebase over time.

4. Selectively Merge Changes

No one enjoys untangling merge conflicts.

When merging branches in Git, it’s common to face conflicts if the changes made in each branch overlap. Fixing these conflicts can be a frustrating, time consuming process that can easily introduce bugs into your code.

Thankfully, cherry-pick can help us avoid this, by allowing us to selectively merge commits/changes from one branch to another.

By default, when cherry-picking a commit that conflicts with the current state of your branch, Git will prompt you to manually resolve the conflicts. This can be time-consuming and error-prone, especially if there are a large number of conflicts to resolve.

However, you can make use of the--strategy-option flag, which allows you to specify a merge strategy for Git to use when applying the cherry-picked commit. e.g. --strategy-option theirs

Using theirs as the merge strategy means that Git will automatically resolve conflicts by using the changes from the commit being cherry-picked (i.e., "theirs") instead of the changes in the current branch. This can be useful when you want to selectively merge changes from one branch to another without having to manually resolve conflicts.

Here’s an example scenario: you have two branches, feature-branch and main-branch, and you want to merge a specific commit from feature-branch to main-branch. However, merging the entire feature-branch would introduce conflicts with changes made in main-branch. To avoid this, you can use cherry-pick to only merge the specific commit you need:

# Checkout the main branch
git checkout main

# Cherry-pick the specific commit from the feature branch
git cherry-pick --strategy-option theirs abc123

This will apply the changes from the abc123 commit in feature-branch to main-branch, without merging the entire branch and introducing conflicts. By using cherry-pick to selectively merge changes, software developers can avoid conflicts and streamline their Git workflow.

5. Split Large Commits Into Smaller, Focused Commits

First off, why should you care about splitting large commits?

Well, smaller, more focused commits are easier to manage and review. It’s much easier to keep track of changes made to a single file or feature, as opposed to a large mix of files and features. Plus, it can help you collaborate better with your team members by providing a more organised commit history.

For instance, let’s say you have a large commit that includes changes to two different files — file1 and file2. You can use cherry-pick to split the commit into two smaller commits, one for each file.

First, use git cherry-pick -n to cherry-pick the original commit without immediately committing the changes.

Then, use git reset to unstage the changes.

Finally, use git add and git commit to create two separate commits, each containing changes for a single file.

Example:

git cherry-pick -n mno345
git reset
git add file1
git commit -m "Fix bug A"
git add file2
git commit -m "Add feature B"

This approach can help you keep your commit history organised and make it easier to track changes over time. Additionally, it can make it easier to review and collaborate on code with other developers.

As you can see, git cherry-pick can be a very powerful tool when used correctly, and offers a much greater range of functionality than it may first appear.

By understanding its potential and using it properly, you’ll be well-equipped to handle complex version control scenarios and maintain a clean, organised codebase.

If you found this article helpful or informative, please consider checking out some of my other articles, and following me on Medium and/or Twitter. Thanks a lot and happy reading!

Level Up Coding

Thanks for being a part of our community! Before you go:

🚀👉 Join the Level Up talent collective and find an amazing job

--

--

Helping developers expand their skill set, advance their careers, or start something new | Building software for 8+ years in start-ups & large companies.