Introduction

Copying commits from one branch to another is a normal Git task when you backport a fix, move a hotfix to a release branch, or recover work that landed on the wrong branch. The usual tool is git cherry-pick, but the right strategy depends on whether you need one commit, a specific range, or an entire branch.

Use cherry-pick for Specific Commits

If you want one commit from another branch, switch to the destination branch and cherry-pick the source commit hash.

git switch release/1.8
git cherry-pick 3f8c2a1

That creates a new commit on the current branch with the same patch content as the original commit. The hash changes because the new commit has a different parent.

This is the standard choice for backports because it copies only the fix you asked for.

Copy Several Commits Deliberately

You can cherry-pick more than one explicit commit:

git switch release/1.8
git cherry-pick a12b45c d67e890

For a contiguous block of history, use a range:

git cherry-pick start_hash^..end_hash

That includes start_hash through end_hash in order. It is useful when a fix spans a short run of clean commits.

Add -x for Traceability

When copying a fix into a maintenance or release branch, -x is often worth using.

git switch release/1.8
git cherry-pick -x 3f8c2a1

Git adds a line to the new commit message showing which original commit it came from. That is helpful later when you need to answer questions such as whether a bug fix was backported from main.

Resolve Conflicts With a Clean Workflow

Cherry-picks can conflict if the destination branch has drifted. The normal conflict workflow is:

1git status
2# edit conflicted files
3
4git add path/to/resolved_file
5git cherry-pick --continue

If you decide the commit should not be copied after all, abort instead of leaving the repository mid-operation.

git cherry-pick --abort

Do not mix unrelated edits into a half-resolved cherry-pick. Finish or abort first.

Use Merge When the Whole Branch Should Move

If you actually want all changes from the source branch, merge may be the cleaner tool.

git switch main
git merge --no-ff feature/payment-retry

A merge preserves branch history and relationships. Cherry-picking many commits one by one is usually the wrong approach when the real intent is to integrate the whole branch.

Verify the Result

After copying commits, inspect both the history and the patch.

git log --oneline -n 5
git show --stat HEAD

Then run the relevant tests or checks for the changed area.

pytest -q

A clean cherry-pick does not guarantee the code still behaves correctly in the destination branch context.

A Practical Backport Workflow

A disciplined backport process keeps history easier to audit:

1. Merge the original fix into the main development branch.
2. Switch to the release branch.
3. Cherry-pick the fix with -x.
4. Resolve conflicts carefully if they appear.
5. Run branch-specific tests.
6. Review the backport separately if your team uses pull requests.

This approach makes it easier to track which supported branches received the fix.

Common Pitfalls

The biggest mistake is cherry-picking a commit without the prerequisites it depends on. A patch may rely on earlier refactors that are missing from the destination branch.

Another common issue is using cherry-pick when merge would better represent the real intent. Developers also sometimes skip verification because the cherry-pick applied cleanly, which is not the same thing as proving the result works.

Summary

• Use git cherry-pick when you need to copy specific commits selectively.
• Use -x when traceability matters, especially for backports.
• Cherry-pick ranges carefully when several adjacent commits belong together.
• Use merge instead when the full branch should move as a unit.
• Always verify the destination branch after copying the commits.