# git cherry-pick -x and -m: Trace and Pick Merges

> git cherry-pick -x records the source commit, and -m picks a side of a merge commit. Reference for backporting in CI plus the conflict and mainline errors.

Source: https://latchkey.dev/learn/command-reference/git-cherry-pick-x-mainline  
Updated: 2026-06-30

git cherry-pick -x appends a "(cherry picked from commit <sha>)" line so backports are traceable, and -m <parent> picks the changes relative to one parent of a merge commit.

Automated backport jobs need two flags the basic cherry-pick guides skip: -x for an audit trail and -m to pick a merge commit at all. This page focuses on those plus conflict handling in non-interactive runs.

## What it does

git cherry-pick applies the change introduced by one or more commits onto the current HEAD. -x adds a provenance line referencing the original SHA. -m N is required to cherry-pick a merge commit: it tells git which parent (usually 1, the mainline) to diff against.

## Common usage

```Terminal
git cherry-pick -x abc1234
# pick a merge commit relative to its first parent
git cherry-pick -m 1 def5678
# range, stopping on conflict for a script to resolve
git cherry-pick -x v1.0..v1.1
# in a script, abort cleanly on conflict
git cherry-pick -x abc1234 || git cherry-pick --abort
```

## Options

| Flag | What it does |
| --- | --- |
| -x | Append "(cherry picked from commit ...)" to the message |
| -m <parent-number> | Pick a merge commit relative to that parent |
| -n / --no-commit | Apply changes but do not commit |
| --continue | Resume after resolving conflicts |
| --abort | Cancel and restore the pre-pick state |
| --skip | Skip the current commit in a range pick |

## In CI

Set an identity (git config user.email / user.name) before cherry-picking, or the commit step fails. In automation, never leave a half-finished pick: wrap with || git cherry-pick --abort so the runner does not exit mid-conflict and poison the next job on a persistent runner.

## Common errors in CI

"fatal: commit <sha> is a merge but no -m option was given" means you must add -m 1. "error: could not apply <sha>... after resolving the conflicts" is a real merge conflict; resolve and --continue or --abort. "fatal: bad revision" usually means a shallow clone lacks the source commit; deepen the fetch.

## Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

```.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached
```

> `git rev-parse --abbrev-ref HEAD` returns the literal string `HEAD` on a detached checkout rather than a branch name. On GitHub Actions read `github.ref_name` instead; the git command cannot know what it was checked out for.

## FAQ

### git cherry-pick -x and -m: Trace and Pick Merges?

Automated backport jobs need two flags the basic cherry-pick guides skip: -x for an audit trail and -m to pick a merge commit at all. This page focuses on those plus conflict handling in non-interactive runs.

### What it does?

git cherry-pick applies the change introduced by one or more commits onto the current HEAD. -x adds a provenance line referencing the original SHA. -m N is required to cherry-pick a merge commit: it tells git which parent (usually 1, the mainline) to diff against.

### In CI?

Set an identity (git config user.email / user.name) before cherry-picking, or the commit step fails. In automation, never leave a half-finished pick: wrap with || git cherry-pick --abort so the runner does not exit mid-conflict and poison the next job on a persistent runner.

### Common errors in CI?

"fatal: commit <sha> is a merge but no -m option was given" means you must add -m 1. "error: could not apply <sha>... after resolving the conflicts" is a real merge conflict; resolve and --continue or --abort. "fatal: bad revision" usually means a shallow clone lacks the source commit; deepen the fetch.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt