How to revert a merge request in GitLab, and how to undo the revert

A merge broke something and the fix isn’t ready. The safe move is a revert: GitLab adds a commit that undoes the merge request, and the history keeps both. Here is how to revert a merge request in GitLab in 2026, what to do when the Revert button is missing, and how to bring the change back once it’s fixed.

What a revert does

A revert doesn’t erase anything. It adds a new commit, the revert commit, that:

• removes the lines the original change added,
• restores the lines it removed,
• puts the lines it modified back as they were.

The original commits stay where they are, so the history shows what happened and when. If the bad change spans several commits, revert the whole merge request rather than one commit at a time.

Revert a merge request

1. In the project, select Code › Merge requests, then the Merged tab, and open the merge request.
2. Scroll to the merge request reports, to the one that shows Merged by.
3. Select Revert.
4. In Revert in branch, choose the branch to revert into, usually the one it was merged into. The field starts on the default branch.
5. Then either:
   • clear Start a new merge request and select Revert, which commits the revert straight away, or
   • keep Start a new merge request selected, fill in the new merge request and select Create merge request. The revert is done when that merge request merges.

A revert merge request goes through your pipeline and review like any other change. Reverting straight away is quicker when the branch is broken, but the revert commit follows your project’s access controls, so you need to be allowed to push to that branch.

Can’t revert it?

• It isn’t merged. Only merged merge requests can be reverted. To drop an open one, close it.
• Your role can’t. You need a role that can edit merge requests and add code to the repository, usually Developer or higher.
• Fast-forward merges. GitLab can revert a merge request merged with a merge commit in one step. With the fast-forward method, it can only if the commits were squashed or the merge request had a single commit; otherwise revert the commits one by one, or use the command line.
• It was already reverted. GitLab won’t apply the same revert twice: the merge request still shows Revert, but a second attempt fails with “Merge request revert failed”. On a commit’s page, Options stops offering Revert once GitLab records the revert.

Revert a single commit instead

To undo one commit and keep the rest:

1. Open the commit. From its merge request, select Commits, then the commit’s title, then the commit hash shown under Viewing commit. Or find it in Code › Commits.
2. In the upper-right corner, select Options, then Revert.
3. Choose Revert in branch and whether to Start a new merge request, as above.

From the command line

Create a branch from the target branch, revert the merge commit, and push it as a merge request:

git fetch origin
git switch -c revert-feature origin/main
git revert -m 1 <merge-commit-sha>
git push -o merge_request.create -o merge_request.target=main origin revert-feature

A merge commit has two parents, and -m 1 tells Git that the first one, the branch you merged into, is the mainline, so the revert takes out what the merge brought in. To revert relative to the other parent, use -m 2. If the merge request was squashed and fast-forwarded, there’s no merge commit: run git revert <squash-commit-sha> without -m. If it was fast-forwarded with a single commit that wasn’t squashed, revert that commit. The merge requests API gives you both SHAs, as merge_commit_sha and squash_commit_sha.

With the API

POST /projects/:id/repository/commits/:sha/revert reverts a commit into the branch you pass as branch. To revert a whole merge request, pass its merge_commit_sha, or its squash_commit_sha if it was squashed and fast-forwarded. Like the Revert button, GitLab reverts a merge commit against its first parent. Set dry_run=true to check that it applies cleanly without committing anything:

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

It returns 201 Created and the revert commit, or 200 OK with {"dry_run": "success"} on a dry run. If the revert doesn’t apply, you get 400 Bad Request with error_code conflict, when a later commit changed the same lines, or empty, when the change has probably been reverted already.

Bring the change back: revert the revert

Once the fix is ready, don’t merge the old branch again. Its commits are already in the target branch’s history, so Git considers them merged and leaves the reverted changes out. As Git’s documentation puts it, reverting a merge commit “declares that you will never want the tree changes brought in by the merge”.

Revert the revert commit instead: open it and select Options › Revert, or run git revert <revert-commit-sha>. That restores the original change, and you can add the fix on top in the same merge request.

When a merge breaks things while you’re away

A bad merge usually announces itself with a red pipeline. On MergeBell Pro, a pipeline watch sends a push when a pipeline on a branch you follow fails. On the free tier, the pipeline opens with live job logs, so you can see what broke, then retry or cancel jobs from your phone. More in how to retry a failed GitLab pipeline.