CHAPTER 05
Advanced
Cherry-Picking and Selective Commits
Updated: May 15, 2026
20 min read
# CHAPTER 5
Cherry-Picking and Selective Commits
1. Introduction
Traditional Git commands operate on entire branches. When you rungit merge, you integrate the entire timeline of one branch into another. But what happens when a timeline contains a mixture of brilliant code and catastrophic bugs? You cannot merge the whole branch without breaking production. In these scenarios, we require surgical precision. Enter Cherry-Picking. In this chapter, we will learn how to extract a single, specific commit from anywhere in the repository's history and inject it directly into our current branch, entirely bypassing the need to merge unwanted code.
2. Learning Objectives
By the end of this chapter, you will be able to:-
Define the operational mechanism of
git cherry-pick.
- Extract a single commit from an alternate branch.
- Extract a range of multiple commits selectively.
- Resolve merge conflicts generated during a cherry-pick operation.
- Understand the implications of cherry-picking on commit hashes.
3. Beginner-to-Advanced Explanations
The Problem: Developer A is working on thefeature/redesign branch. Over two weeks, they make 20 commits. Commit #5 contains a brilliant security patch for the database. However, the other 19 commits contain a half-finished, broken UI redesign.
The company needs that security patch in the main production branch immediately.
-
If you
git merge feature/redesignintomain, you get the security patch, but you also pull in the broken UI, crashing the website.
The Solution (Cherry-Picking):
You use git log to find the exact SHA-1 hash of the security patch commit (e.g., a1b2c3d).
You stand on the main branch and command Git to literally reach across the repository, copy the exact changes made in commit a1b2c3d, and apply them as a brand new commit on main. The broken UI commits are completely ignored.
4. Real-World Workflow Examples
The Hotfix Backport: In Enterprise Git Flow (Chapter 3), you have arelease/v1.0 branch that is live in production, and a develop branch for v2.0.
A customer reports a bug in v1.0. You fix the bug directly on the release/v1.0 branch (Commit X).
However, that bug also exists in the develop branch! Instead of rewriting the code, you switch to develop and run git cherry-pick X. The fix is instantly duplicated to the future version. This is called "backporting" a fix.
5. Git Command Walkthroughs
The syntax for cherry-picking requires you to know the commit hash.
bash
6. Cherry-Picking Conflicts
Because cherry-picking is mathematically similar to rebasing (applying a patch from one timeline onto another), it can generate conflicts! If the security patch you are cherry-picking editsdatabase.php on line 10, but the main branch doesn't even have a database.php file yet, Git will halt and throw a conflict.
-
You resolve the conflict using standard tools (
git mergetool).
-
You stage the fix:
git add database.php
-
You conclude the operation using:
git cherry-pick --continue
7. Mini Project: Move Commits Between Branches
Let's simulate a selective extraction.Step-by-Step Walkthrough:
-
1.
Create a repository:
mkdir cherry-demo && cd cherry-demo && git init
-
2.
Create the base:
echo "V1" > app.txt && git add . && git commit -m "Base"
-
3.
Create a feature branch:
git checkout -b experimental
-
4.
Add bad code:
echo "Bad UI" >> app.txt && git commit -am "Add broken UI"
-
5.
Add the diamond:
echo "function fixSecurity(){}" > secure.js && git add . && git commit -m "CRITICAL SECURITY FIX"
-
6.
Add more bad code:
echo "More broken UI" >> app.txt && git commit -am "Add more broken UI"
-
7.
*The Goal:* We only want the security fix on
main. Rungit log --onelineand copy the hash of the "CRITICAL SECURITY FIX" commit (e.g.,4a5b6c7).
-
8.
Switch back to safety:
git checkout main
-
9.
The Extraction: Run
git cherry-pick 4a5b6c7
-
10.
Run
git log --onelineonmain. You will see the base commit and the security fix, perfectly isolated from the broken UI code!
8. Best Practices
- Use as a Last Resort: While cherry-picking is a powerful surgical tool, it should not be your primary collaboration workflow. Constant cherry-picking results in identical code modifications having different SHA hashes across multiple branches, which makes future merges chaotic. Rely on clean branching and rebasing first; use cherry-picking for emergencies and backports.
9. Common Mistakes
-
Forgetting the Hash Changes: When you cherry-pick commit
Afrom branch X to branch Y, Git creates a *brand new commit object* on branch Y. It has the same message and code, but a completely different SHA-1 hash. It is a clone, not a shared reference.
10. Exercises
-
1.
Describe a specific enterprise scenario where
git cherry-pickis mathematically safer thangit merge.
- 2. If a cherry-pick operation results in a file conflict, what command is used to finalize the operation after resolving the conflict?
11. FAQs
Q: What if I cherry-pick a commit and instantly realize it was the wrong one? A: You can abort an in-progress, conflicted cherry-pick usinggit cherry-pick --abort. If the cherry-pick was already completed and committed, you can simply use git reset --hard HEAD~1 to wipe the cloned commit off your branch.
12. Summary
In Chapter 5, we mastered the art of selective integration. We transcended the limitations of branch-wide merging, utilizinggit cherry-pick to surgically extract isolated, high-value commits from otherwise unmergeable timelines. We explored the enterprise concept of "backporting" hotfixes across version branches and successfully executed an extraction while bypassing surrounding toxic code. We recognized that while cherry-picking is an invaluable emergency and maintenance tool, it must be wielded carefully to prevent hash fragmentation across the repository graph.