Git Cherry-Pick: How to Move Commits Between Branches Safely
Need to move commits between branches? Learn how to use git cherry-pick, resolve merge conflicts, and follow best practices to keep your history clean.
Last month, I was debugging a production issue in our payment gateway when I realized the fix was buried inside a feature branch that wasn't ready for deployment. I needed that single commit, but merging the entire feature branch would have dragged in half-finished code and broken our build.
That’s exactly when git cherry-pick becomes your best friend. It allows you to grab a specific commit from one branch and apply it to another, effectively letting you pick and choose exactly what gets merged.
Understanding Git Cherry-Pick
When you run git cherry-pick <commit-hash>, Git takes the changes introduced by that specific commit and creates a new commit on your current branch. It’s important to remember that this creates a new commit object with a different hash, even though the changes are identical.
Before you dive in, make sure your working directory is clean. I usually run git status first to ensure I don't have any uncommitted changes hiding in the shadows. If you've been working on long-running features and need to recover work you accidentally overwrote, you might want to look at my previous Git Reflog Tutorial: Recover Lost Commits and Abandoned Branches before proceeding.
How to Move Commits Between Branches
The process is straightforward. First, identify the commit hash you want to move. You can find this using git log --oneline.
- Checkout the target branch:
git checkout main - Run the cherry-pick:
git cherry-pick a1b2c3d - If there are no conflicts, Git will prompt you to edit the commit message (or use the original). Save and exit, and you're done.
If you need to move a series of commits, you can cherry-pick a range:
git cherry-pick A..B (where A is the oldest commit and B is the newest). Note that this excludes commit A itself; if you need to include it, use git cherry-pick A^..B.
How to Resolve Cherry-Pick Conflicts
Sometimes, the code you are picking modifies lines that have changed in the target branch. This will trigger a conflict. Don't panic—Git will pause the process and let you fix it.
When the cherry-pick stops, your terminal will show you which files are in conflict. Open them, resolve the differences, and follow these steps:
- Stage the resolved files:
git add <file-name> - Continue the process:
git cherry-pick --continue
If you realize you’ve made a mistake and want to back out, run git cherry-pick --abort to return your branch to its original state.
Comparison: Merge vs. Cherry-Pick
| Feature | Git Merge | Git Cherry-Pick |
|---|---|---|
| Scope | Entire branch history | Specific, single commits |
| Commit History | Preserves original structure | Creates new commit hashes |
| Complexity | Lower (standard workflow) | Higher (manual management) |
| Best For | Integrating features | Hotfixes, backporting |
Git Workflow Best Practices
While git cherry-pick is powerful, it shouldn't be your default way of moving code. If you find yourself doing it constantly, you probably have a structural issue with your branching strategy.
- Avoid duplication: If you cherry-pick a commit and later merge the entire source branch, you might end up with duplicate commits or messy merge conflicts.
- Keep it small: Only pick commits that are atomic and focused. If a commit does five different things, you'll struggle to isolate the logic you actually need.
- Communicate: If you are working on a shared team branch, let your teammates know you're cherry-picking. It changes the history and can cause confusion for others pulling the code.
I’ve learned the hard way that "cherry-picking" your way to a release is a recipe for technical debt. It's fine for the occasional hotfix, but if you're using it to bypass proper pull request reviews, you're setting yourself up for a headache.
Next time, I’d like to experiment more with git rebase for cleaner history, though I’m still cautious about rebasing shared branches. Have you ever had a cherry-pick go sideways? It’s usually the moment you realize you didn't check the file diffs closely enough before running the command.
Frequently Asked Questions
Can I cherry-pick multiple commits at once?
Yes. You can list them separated by spaces: git cherry-pick <hash1> <hash2> <hash3>. They will be applied in the order you list them.
What happens to the original commit?
Nothing. The original commit remains exactly where it was in the source branch. Cherry-pick only creates a copy in your current branch.
Is it safe to cherry-pick to a production branch?
It's common for hotfixes, but be careful. Ensure you have tested the specific commit in a staging environment first, as the target branch might have different dependencies or code states that conflict silently.