How do I cherry-pick a merge commit?

Use git cherry-pick -m 1 . The -m 1 tells git which parent to treat as the main line — for a PR merge commit, parent 1 is the target branch, so the diff applied is 'everything the PR changed'.

Does cherry-pick preserve the original author?

Yes, the author name and date are kept; you become the committer. For PRs with several contributors, make sure the commit messages carry Co-authored-by lines so credit survives the trip.

Can I backport one PR to several release branches?

Yes, but each branch is its own cherry-pick with its own conflict risk — a fix that applies cleanly to release/2.1 can conflict hard on release/1.9. Preview each target separately instead of assuming one result covers all.

Cherry-pick or merge — which is right for backports?

Cherry-pick. Merging main into a release branch drags in every other change since the branch point, which defeats the purpose of a stable release line. Backports should move exactly the fix, nothing else.

How to backport a pull request to another branch

The fix landed on main, but your release branch needs it too. How to cherry-pick a PR onto another branch — and how to see the conflicts coming before you're in them.

The scenario every maintainer knows: the bugfix merged into main yesterday, and now support wants it in release/2.1, which branched off three months ago. You don't want all of main — you want that one change, moved backwards in time. That's a backport.

The manual way: cherry-pick

Git's tool for this is git cherry-pick — it takes the diff of a commit and replays it onto your current branch as a new commit.

git fetch origin
git checkout -b backport/fix-login-to-2.1 origin/release/2.1
git cherry-pick abc1234
git push origin backport/fix-login-to-2.1

Then open a PR into release/2.1 as usual.

If the PR was squash-merged, there's exactly one commit to pick — easy. If it merged with a merge commit and you want the whole PR in one go, cherry-pick the merge commit with -m 1 ("parent 1 is the main line, apply everything the other side brought"). If it was a regular multi-commit PR, pick the commits oldest-first.

Where it stops being fun

Conflicts arrive blind. The release branch has drifted from main for months. Whether the fix's files still look anything like what the patch expects is a coin flip — and you only find out after you're mid-cherry-pick with a dirty tree.

The blast radius multiplies. One fix, three supported release branches: three cherry-picks, three independent conflict sessions, three PRs. Miss one and a customer on the old branch hits a bug you fixed months ago.

Authorship gets murky. Cherry-pick keeps the author but makes you the committer, and multi-author PRs lose their co-author trailers unless you carry them over by hand.

The git.tools way

Backport with a preview, not a prayer

Pick the PR and the target branch. git.tools classifies every changed file up front — applies cleanly, conflicts, or already there — and lets you decide per conflicting file before it opens a single pull request on the target branch.

Open Backport →

Backport hygiene that pays off

Backport the fix, not the feature. If the PR mixed the bugfix with refactoring, pick only the commits that matter — smaller diffs conflict less.
Newest branch first. Porting to the closest release first gives you the easiest conflicts and a tested patch to carry forward.
Never merge main into the release branch as a shortcut. That pulls in months of unrelated change and your "stable" line stops being one.
Let CI do the arguing. Always backport via a PR, even if you have push rights — the release branch's test suite is the only honest answer to "does this patch still work back here?"