When do you need to ‘pick’ a commit instead of merging the whole branch?
Suppose you’ve been working on a feature in the feature-xyz branch all week. Suddenly, a client reports a critical bug on Production that needs an immediate fix. You realize you accidentally fixed that exact bug in a single commit buried within the unfinished code of your feature branch.
At this point, merging the entire branch into main is impossible because the new feature hasn’t finished testing. If you force the push, the system could easily crash. Manually copying and pasting code also carries high risks of errors. This is exactly when Git Cherry-pick becomes a powerful tool. This command allows you to pick that specific bug-fix commit and apply it cleanly to the main branch.
In practice, when working on large projects with 10-20 developers, Cherry-pick is frequently used for ‘backporting’ (bringing patches from newer versions back to older ones). It helps you control the code flow without disrupting the team’s entire commit history.
Comparing Cherry-pick with Merge and Rebase
To use it correctly, you need to distinguish Cherry-pick from its two siblings: Merge and Rebase.
- Git Merge: Integrates the entire history of one branch into another. This is like pouring a whole bucket of water into a large basin; sometimes it brings along things you didn’t want.
- Git Rebase: Rewrites history by placing the commits of one branch on top of another. It creates a perfectly linear Git history but is extremely risky if you have already pushed code to the server.
- Git Cherry-pick: Selects only one or a few specific commits. It’s like picking a specific brick you like from a pile of rubble to use for your own house.
Quick Comparison Table:
| Feature | Merge | Rebase | Cherry-pick |
|---|---|---|---|
| Scope | Entire branch | Entire branch | Single commit |
| Git History | Creates merge commit | Linear, clean | Creates new commit (new hash) |
| Risk Level | Low | Very high | Medium |
Why should (and shouldn’t) you use Cherry-pick?
Pros:
- Absolute Control: You only take what is necessary, completely eliminating junk code.
- Production Rescue: Helps deploy Hotfixes quickly without waiting for other features to be completed.
- Multi-version Support: When a project runs v1.0 and v2.0 in parallel, you can apply a patch to both versions without rewriting code twice.
Cons:
- Causes Duplication: Cherry-pick creates a new Hash. If overused,
git logwill be cluttered with commits that have identical content but different identifiers. - Prone to Conflicts: If the commit you pick depends on an older piece of code that you haven’t brought over, a conflict is inevitable.
How to Implement Git Cherry-pick in 3 Steps
First, find the Hash of the commit you want to take using the command:
git log --onelineSuppose the required commit hash is a1b2c3d.
1. Cherry-pick a single commit
Switch to the target branch (e.g., main) and execute the command:
git checkout main
git cherry-pick a1b2c3d2. Pick multiple commits at once
To pick a list of discrete commits, use the syntax:
git cherry-pick hash1 hash2 hash3If you want to take a range of commits from A to B (excluding A), use A..B. To include commit A, use A^..B.
3. Tips for maintaining origin traces
A hard-earned lesson is to always use the -x option. It will automatically add a note to the message indicating where this commit was ‘picked’ from.
git cherry-pick -x a1b2c3dThis is extremely useful later when you need to trace bugs or debug the system.
Handling Conflicts: Don’t Panic!
A conflict occurs when the line of code you are picking has already been changed in the target branch. When you see an error message, stay calm and follow this process:
- Open the conflicting file, find the
<<<<<<<and=======symbols to fix it manually. - Save the file after selecting the correct code.
- Run the command
git add <file_name>to mark it as resolved. - Resume the process with the command:
git cherry-pick --continue.
If it feels too complicated and you want to return to the previous state, simply type git cherry-pick --abort.
Real-world Story: When Cherry-pick Saved the Project
I once worked on an outsourcing project with a very strict Git Flow process. A colleague accidentally committed new feature code directly into the develop branch, just as this branch was being prepared for a client demo the next morning. The entire feature code was still unfinished and could cause the application to crash.
Instead of manually deleting code across more than 15 affected files, I handled it in 5 minutes:
- Moved that incorrect commit to the correct
featurebranch using Cherry-pick. - Returned to
developand usedgit revertto undo the changes.
As a result, the demo went perfectly. The feature code remained preserved for continued development in its own branch. Without Cherry-pick, the whole team might have had to pull an all-nighter to clean up that mess.
Final Advice:
- Only Cherry-pick when absolutely necessary. Don’t let it become a habit that replaces Merge.
- If you have to pick more than 10 commits at once, review your team’s workflow. You might be heading in the wrong direction.
- Always run Unit Tests immediately after picking a commit to ensure everything still functions smoothly.
