Backporting with Cherry-pick

What you will learn

• Understand the core purpose of Backporting with Cherry-pick
• Master the basic usage and common options of Backporting with Cherry-pick
• Backport precise fixes onto maintenance branches without merging an entire feature branch.
• Understand key concepts: Where this workflow fits
• Know when to use this feature and when to avoid it

Start with a problem

Your team is collaborating on a project, branches are growing, merges are becoming more frequent — but there's no stable collaboration rhythm. Everyone syncs code their own way, and conflicts are piling up.

Where this workflow fits

main (trunk)

main

ABC

feature

BDE

git cherry-pick <commit-hash>

release/2.x (maintenance)

release

AR1E'

When a fix already landed on main but an older maintenance line still needs it, the usual problem is:

"I need this one repair, not the whole branch history."

That is when cherry-pick is a strong fit.

Suggested sequence

1. identify the exact commit

git log --oneline --decorate main

The first risk in backporting is not conflict. It is choosing the wrong commit.

2. switch to the maintenance branch and cherry-pick

git switch release/2.3
git cherry-pick <commit-sha>

3. validate the resulting diff and tests

git show --stat --oneline HEAD
git diff --stat origin/release/2.3...

Do not stop at "the command succeeded." Confirm the resulting change still makes sense on the older branch.

Why this order is safer

Backporting works best when the order is fixed:

1. confirm the right commit
2. confirm the target maintenance branch
3. confirm the fix still stands alone after the pick

Common mistakes

• cherry-picking before checking dependency commits
• backporting multiple commits without thinking through order
• assuming a successful cherry-pick means the fix is release-ready

Special cases

• if the fix depends on earlier refactors, a single cherry-pick may not be enough
• if the old branch has different config or schema expectations, validate in branch context
• if multiple maintenance lines need the same repair, verify one branch before repeating the flow

Try it yourself

1. Practice the backport-with-cherry-pick command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process

Further reading

Keep going on the same topic:

• API Versioning Change Workflow
• Bisect Regression Triage Workflow
• Canary Release Workflow