How to Cherry-Pick One Git Commit onto Another Branch

To copy one commit's change onto another branch, check out the branch that should receive it and run git cherry-pick with that commit's ID. Git applies the selected change there; it does not move the original commit or automatically copy the source branch's earlier work.

This walkthrough is for one ordinary commit with one parent. The example copies a documentation correction from feature/docs onto a new review branch based on main. Use your repository's actual names and an approved, up-to-date destination base. Release fixes with dependencies need the additional checks in our release-backport guide.

1. Find the commit and read its patch

List recent commits on the source branch:

git log --oneline -n 10 feature/docs

Copy the correction's commit ID. In the commands below, replace the literal FIX_COMMIT with that ID; it is a placeholder, not a Git keyword. If the source history is missing locally, fetch it through your project's normal process first.

git show --stat FIX_COMMIT
git show FIX_COMMIT
git show --no-patch --format=%P FIX_COMMIT

The first two commands show the affected files and actual patch. Check that the commit contains only the change you want and makes sense without the surrounding work. The last command prints its parent IDs: this walkthrough expects one. Two or more means a merge commit, which needs a deliberate mainline choice rather than this recipe. Git's show reference documents the patch and parent output.

2. Start clean on the receiving branch

Check for unfinished work or another operation in progress:

git status

Commit or otherwise preserve work you need before proceeding. If you only need to set it aside briefly, saving changes with Git stash covers tracked and untracked files. Do not discard edits just to make a cherry-pick run.

Create a review branch from the intended base, then check its name and state:

git switch -c copy/docs-correction main
git status --short --branch

Expect the branch name copy/docs-correction and no changed paths. The main here is your local branch, not a promise that it matches the remote. Confirm the base beforehand. If the new branch name already exists, choose an unused name rather than changing -c to the resetting -C option. See Git's branch-creation options.

3. Apply that one commit

git cherry-pick FIX_COMMIT

The receiving branch is the one you have checked out—not feature/docs, and not a branch named inside the commit message. On a successful pick, Git records the change there. Its commit ID will usually differ from the original; the source branch remains unchanged. This is the ordinary operation described in Git's cherry-pick manual.

If reviewers can access the source commit and need a trace back to it, use git cherry-pick -x FIX_COMMIT instead of the command above. Inspect the resulting message for the source reference; do not run both commands.

4. Check what arrived

git show --stat --oneline HEAD
git show HEAD
git status --short --branch

Confirm that the latest commit contains the correction, no unrelated changes travelled with it, and you are still on the intended branch. Run checks appropriate to the edit: for documentation, that might include rendering the page and checking the example it corrects; for code, run the relevant tests. Then submit the review branch through the project's usual process.

In a disposable check of this example, a spelling correction reached the new branch while an earlier, unrelated change on feature/docs stayed behind. The source commit remained on its original branch, and the copied correction had a different ID.

If the pick stops instead of completing

Run git status and read the reason before trying again. A conflict or empty result needs a decision, not a second invocation of the same pick. To abandon an in-progress pick that you started from a clean state:

git cherry-pick --abort

This cancels the operation; it does not undo an already completed cherry-pick. For a completed commit that has been shared, use the project's correction process—reverting a shared Git commit explains the history-preserving approach.

Command checks were run in disposable repositories with Git 2.52.0 on 29 October 2026. They verify this Git workflow, not the correctness of a change in your project.