How to cherry-pick a GitLab merge request into another branch

You merged a fix into main, and release-1.2 needs it too. Cherry-picking copies the changes of one commit, or of a whole merge request, onto another branch without bringing the rest of the branch along. Here is how to do it in GitLab in 2026: in the browser, with Git and with the API.

Cherry-pick a merged merge request

1. Open the merge request. It has to be merged already.
2. Scroll to the merge request reports, to the one that shows Merged by, and select Cherry-pick in its upper-right corner.
3. In Pick into project, choose the project, and in Pick into branch, the branch.
4. Start a new merge request with these changes is selected by default. Clear it to commit straight into the branch. Keep it, and GitLab commits to a new branch, cherry-pick- and the commit’s short SHA, then opens the new merge request form for it. Copy merge request description, shown while the box is selected, fills that form with the original description.
5. Select Cherry-pick, and if you kept the box selected, finish the form and select Create merge request.

With the box cleared, GitLab confirms with “The merge request has been successfully cherry-picked into release-1.2.” When it cherry-picks a merge commit, it also adds a note to the original merge request saying who picked the changes into which branch, with the new commit, so the trail is easy to follow later.

When there’s no Cherry-pick button

• It isn’t merged yet. The button appears once the merge request is merged.
• Your project uses fast-forward merges. GitLab can cherry-pick a merge request in one step when the merge left a merge commit, as the merge commit and semi-linear methods do. With the fast-forward method, it can only when the merge request was squashed or has a single commit, and it adds no note to the merge request.
• One commit is enough. Whatever the merge method, open the commit from Code › Commits, or from a file’s History, and select Options › Cherry-pick.
• Your role can’t. You need a role that can edit merge requests and add code to the repository, usually Developer or higher.

What the new commit looks like

The cherry-picked commit keeps the original message and adds (cherry picked from commit <SHA>). When it comes from a merge request, the merge request’s commits are listed under that line. You’re the author of the new commit, and the original commit’s author is credited in a Co-authored-by trailer.

When GitLab can’t do it

Merge request cherry-pick failed: Can’t perform this action automatically. It may have already been done, or a more recent commit may have updated some of this content. Please perform this action locally.

For a single commit the message starts with “Commit cherry-pick failed”. Either way there are two causes: the changes conflict with the target branch, or the branch already has them, so the cherry-pick would change nothing. Do it locally, as below, and Git shows you which.

With Git

git fetch origin
git switch release-1.2
git pull --ff-only
git cherry-pick -x 4f2a9c1e
git push origin release-1.2

• -x adds the same “(cherry picked from commit …)” line GitLab adds. Unlike GitLab, Git keeps the original author and makes you the committer, with no trailer.
• A merge commit needs -m 1: git cherry-pick -x -m 1 <merge commit SHA> applies the changes the merge brought into its first parent, the branch it was merged into.
• Several commits: git cherry-pick -x A^..B picks A through B. A..B leaves A out.
• Conflicts: fix the files, git add them, and run git cherry-pick --continue. git cherry-pick --abort puts the branch back as it was.

If the release branch is protected, put the cherry-pick on a new branch and open the merge request in the same push (more push options):

git switch -c backport-login-fix origin/release-1.2
git cherry-pick -x -m 1 <merge commit SHA>
git push -o merge_request.create -o merge_request.target=release-1.2 origin backport-login-fix

With the API

curl --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --data "branch=release-1.2" \
  --url "https://gitlab.example.com/api/v4/projects/5/repository/commits/<sha>/cherry_pick"

• dry_run=true tries it without committing, and answers 200 with {"dry_run": "success"} when it applies cleanly.
• message replaces the whole commit message, including the “(cherry picked from commit …)” line and the Co-authored-by trailer.
• It commits straight to branch, so you need to be allowed to push there, and the API opens no merge request. For a protected branch, create a new branch first, cherry-pick into it, and open a merge request from it.
• A failure answers 400, with error_code conflict when the changes clash, or empty when the branch already has them.

Cherry-pick or revert?

A cherry-pick copies a change to another branch. A revert undoes it, usually on the branch it was merged into. Both buttons sit in the same report on the merged merge request.

Reviewing the backport from your phone

Cherry-picking is a desk job; reviewing the backport isn’t. When you start a new merge request for it and request a review, each reviewer gets a To-Do, which MergeBell turns into a push. They can read the diff, approve and merge it from their phone, on the free tier, on iPhone and Android. If it won’t merge, why can’t I merge my GitLab merge request? covers the reasons.