GIT-REVERT(1)

📦
version 2.56.0 · 28 versions
, in arch rolling

💅 git-revert(1) — the "undo that commit, but politely" manual

okay so bestie, welcome to git-revert(1), straight out of the Git Manual ✨ this is the page about taking a commit that already happened and gently reversing it with a brand-new commit. no history rewriting, no drama, just vibes and counterspell commits 🫶

✨ NAME ✨

git-revert — revert some existing commits 💖

🦋 SYNOPSIS 🦋

git revert [--[no-]edit] [-n] [-m <parent-number>] [-s] [-S[<keyid>]] <commit>...
git revert (--continue | --skip | --abort | --quit)

two whole modes, bestie: the "revert some stuff" line, and the "sequencer damage control" line 🎀

💜 DESCRIPTION 💜

okay so picture this: you hand it one or more existing commits, and git revert reverses the changes that the related patches introduce, then records some new commits that record that reversal. iconic behaviour honestly. the one catch — your working tree has to be clean (no modifications from the HEAD commit), so no sneaky half-finished edits lying around 🙈

⚠️ note time, and this one lowkey matters: git revert is the tool for recording new commits that reverse the effect of some earlier commits (often just one faulty one, we've all been there 😭). if what you actually want is to throw away all uncommitted changes in your working directory, go look at git-reset(1) instead, especially the --hard option. and if you want to extract specific files as they were in another commit, that's git-restore(1), specifically its --source option. be careful with these alternatives, bestie, because both will discard uncommitted changes in your working directory 💀

also, for the full breakdown of the differences between the three commands, see "Reset, restore and revert" in git(1) 🌸

💅 OPTIONS 💅

  • <commit>... — the commits you're reverting, periodt. want a more complete list of ways to spell commit names? that's gitrevisions(7). you can also hand it sets of commits, but no traversal is done by default — see git-rev-list(1) and its --no-walk option for that 🧚
  • -e, --edit — with this one, git revert lets you edit the commit message before committing the revert. this is literally the default when you run the command from a terminal, so it's giving "default behaviour, but make it official" ✨
  • -m parent-number, --mainline parent-number — okay so usually you can't revert a merge, because nobody knows which side of the merge should count as the mainline. this option specifies the parent number (starting from 1) of the mainline, and lets revert reverse the change relative to that specified parent 🎀 reverting a merge commit declares that you will never want the tree changes brought in by that merge. consequence? later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. this may or may not be what you want, so read that twice ngl. see the revert-a-faulty-merge How-To[1] for more details 👑
  • --no-edit — with this, git revert will not start the commit message editor. no editor, no waiting, just commit 🫶
  • --cleanup=<mode> — decides how the commit message gets cleaned up before being passed on to the commit machinery. see git-commit(1) for the deets. in particular, if <mode> is given the value scissors, then scissors will be appended to MERGE_MSG before being passed on in the case of a conflict ✂️
  • -n, --no-commit — usually the command automatically creates some commits with commit log messages stating which commits were reverted. this flag applies the changes necessary to revert the named commits to your working tree and the index, but does not make the commits. bonus: when you use this option, your index does not have to match the HEAD commit — the revert is done against the beginning state of your index 🌈 this is useful when you're reverting more than one commits' effect to your index in a row, iykyk 💫
  • -S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign — GPG-sign commits 🔐 the keyid argument is optional and defaults to the committer identity; if you specify it, it must be stuck to the option without a space. --no-gpg-sign is useful to countermand both the commit.gpgSign configuration variable and earlier --gpg-sign — it's the "nvm, unsigned" button 🙅
  • -s, --signoff — adds a Signed-off-by trailer at the end of the commit message. see the signoff option in git-commit(1) for more info 🖊️
  • --strategy=<strategy> — use the given merge strategy. should only be used once. see the MERGE STRATEGIES section in git-merge(1) for details ⭐
  • -X<option>, --strategy-option=<option> — passes the merge strategy-specific option through to the merge strategy. see git-merge(1) for details 💫
  • --rerere-autoupdate, --no-rerere-autoupdate — after the rerere mechanism reuses a recorded resolution on the current conflict to update the files in the working tree, this allows it to also update the index with the result of that resolution. --no-rerere-autoupdate is a great way to double-check what git-rerere(1) did and catch potential mismerges, before committing the result to the index with a separate git-add(1) 👀
  • --reference — instead of starting the body of the log message with This reverts <full-object-name-of-the-commit-being-reverted>., it refers to the commit using --pretty=reference format (cf. git-log(1)). the revert.reference configuration variable can be used to enable this option by default 🎀

🎀 SEQUENCER SUBCOMMANDS 🎀

these are the "omg something went sideways, what now" commands 🫶

  • --continue — continue the operation in progress using the information in .git/sequencer. can be used to continue after resolving conflicts in a failed cherry-pick or revert 💪
  • --skip — skip the current commit and continue with the rest of the sequence. "not this one, next" ✨
  • --quit — forget about the current operation in progress. can be used to clear the sequencer state after a failed cherry-pick or revert 🧹
  • --abort — cancel the operation and return to the pre-sequence state. the "actually, never mind, rewind" button 😌

🌈 EXAMPLES 🌈

git revert HEAD~3

reverts the changes specified by the fourth last commit in HEAD, and creates a new commit with the reverted changes 💖 (yes, HEAD~3 is the fourth last — git counts from zero-ish, we don't make the rules 🥲)

git revert -n master~5..master~2

reverts the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but does not create any commit with the reverted changes. this one only modifies the working tree and the index — very "I'll commit when I'm ready" energy 💅

👑 DISCUSSION 👑

so git does create a basic commit message automatically, but it is strongly recommended that you explain why the original commit is being reverted. future you will thank present you, fr fr 🫶

also — and this is the funny part — repeatedly reverting reverts will result in increasingly unwieldy subject lines, like, for example:

Reapply "Reapply "<original-subject>""

😭😭😭 please consider rewording these to be shorter and more unique. your git log will look so much better for it 💜

🍓 CONFIGURATION 🍓

everything below this line in this section is selectively included from the git-config(1) documentation, and the content is the same as what's found there 🎀

  • revert.reference — setting this variable to true makes git revert behave as if the --reference option is given. one little config, all the vibes ⭐

🌸 SEE ALSO 🌸

💖 GIT 💖

part of the git(1) suite, obviously 👑

📎 NOTES 📎

  1. revert-a-faulty-merge How-To — file:///usr/share/doc/git-doc/howto/revert-a-faulty-merge.html 🔗

<div align="center">

okay bye bestie, go revert responsibly 💅✨ this page is your bestie-signed, slay-certified rewrite of Git 2.56.0, dated 2026-09-27 — the manual name is GIT-REVERT(1) in case you forgot already 🎀💖🦋

</div>

📦 where this page comes from