doc/user/project/merge_requests/revert_changes.md
{{< details >}}
{{< /details >}}
Mistakes happen in code. Version control makes it possible to fix those mistakes by reverting them.
When you revert a commit, you create a new commit (a revert commit) that reverses the bad change, rather than erasing the existence of the problem from your project's history. Revert commits provide a clear audit trail, rather than a gap where the previous commit was. The revert commit follows your project's access controls and processes, and:
Reverts are not limited to just commits. If the bad change spans more than one commit, consider reverting all changes from the merge request, rather than reverting commit by commit. This approach provides a cleaner audit trail.
After a merge request merges, you can revert all changes in the merge request.
Prerequisites:
You must have a role for the project that allows you to edit merge requests, and add code to the repository.
Your project must use the merge method Merge Commit, set in your project's Settings > Merge requests.
In GitLab 16.9 and later, you can revert fast-forwarded commits from the GitLab UI if either:
For more information, see issue 22236.
To revert merge request Example:
Example).Example is complete.Example is complete.You can revert any commit in a repository into either:
Prerequisites:
To do this:
00001111,
where 00001111 is the hash of the commit. Select the commit hash to show
the commit's page.When you revert a merge commit, the branch you merged to (often main) is always the
first parent. To revert a merge commit to a different parent, you must revert the commit from
the command line, see revert and undo changes with Git.
For more information on redacting text from a repository and other techniques to remove data, see repository size.
git revert documentation