What can you fix after a commit is made?
Two kinds of mistakes show up after you commit. The first is small and fresh: you spot a typo in the commit you made a minute ago, or you forgot to stage one file, or the message is misspelled. The second is older: a commit from yesterday, or from last week, turned out to be wrong and you want its effect gone.
Git gives you a different tool for each. git commit --amend replaces the most recent commit with a corrected one. git revert leaves history alone and adds a new commit that does the opposite of an older one. Picking the right one depends mostly on one question: has anyone else got a copy of the commit you want to change?
Open the Graph view before you try either. Each fix leaves a different shape there, and seeing that shape is the quickest way to understand what each command really did.
How does git commit --amend work?
Amending takes whatever is in the staging area right now and builds a new commit from it, with the same parent as the last commit. The old last commit is then dropped from the branch. Your branch ends up with the same number of commits, and the top one has the fix in it.
In the bakery repository the last commit, "Add the menu", spells sourdough as Sourdouh. Fix the word in index.html, stage the file, then amend. With --no-edit Git keeps the old message. With -m "..." you give a new one. Watch the top dot in the Graph: it gets a brand-new short id, because it is a brand-new commit.
Real Git opens a text editor when you run git commit --amend with no message option, so you can change the message there. The practice terminal has no editor, so use --no-edit or -m.
git log --oneline
git commit --amend -m "Add the bakery menu"
git log --onelineWhen should you amend instead of making a new commit?
Amend when the fix belongs to the commit you just made and nobody else has it yet. A forgotten file, a typo you introduced a moment ago, a bad message: these make the commit incomplete, and amending makes it whole. Your history then reads as one clean step, "Add the menu", instead of "Add the menu" followed by "Fix typo in menu" followed by "Actually add the CSS".
Make a new commit when the change is a separate idea, even if it is small. Changing a price is a new decision and deserves its own message. A separate commit also makes sense once you have pushed the original, which the next answer covers.
Amend only touches the last commit. To fix something three commits back, the usual tools are interactive rebase (not available in the practice terminal) or a revert. For beginners, revert is the safer habit.
Why is amending a pushed commit risky?
An amended commit is a different commit with a different id. If you already pushed the original to GitHub, the remote still has the old one, and your branch now has a replacement. Git sees two branches that have split apart. A normal git push is refused, and the only way through is git push --force, which overwrites what is on the remote.
If a teammate from the bird club or the bakery already pulled the old commit, a force push leaves them with history that no longer exists on GitHub. Their next pull gets confusing fast. The rule most teams follow: amend freely before you push, and never amend something other people may have pulled.
AI assistants often suggest git commit --amend followed by git push --force to tidy up a message. On a branch only you use, that is fine. On main in a shared repository, ask before doing it, or use a revert or a new commit instead.
How does git revert undo an older commit?
git revert <commit> looks at what that commit changed and makes a new commit that changes it back. If the commit added a line, the revert removes it. If it deleted a file, the revert brings the file back. The original commit stays exactly where it was, and the new commit sits on top with a message like Revert "Add opening hours".
Because nothing is rewritten, revert is safe on shared branches. Everyone who pulls gets one more ordinary commit. Nobody needs to force anything. The Graph shows this clearly: one extra dot appears at the top, and every older dot keeps its id.
The practice terminal makes revert commits straight away. Real Git opens an editor so you can adjust the revert message; add --no-edit there to accept the default. Run git show HEAD afterwards to see exactly which lines the revert put back.
git revert HEAD
git log --oneline
git show HEADHow do you pick the right commit to revert?
Run git log --oneline and read the messages. Each line starts with a short id such as 3f9a2c1. Pass that id to git revert, or use a relative name: HEAD is the last commit, HEAD~1 the one before it, HEAD~2 the one before that.
Check with git show <id> before reverting. It prints the commit's message and the exact lines it changed, so you can confirm you are about to undo the right thing. Reverting the wrong commit is fixable (revert the revert), but it adds noise to history.
Commits that only add things are the easiest to revert. If later commits edited the same lines again, Git cannot always undo the old change cleanly and stops with a conflict. The practice terminal is stricter than real Git here: it refuses whenever the same file changed again later, while real Git compares individual lines and only stops if they overlap.
git log --oneline
git show HEAD~1
git show HEAD
git revert HEADWhat do amend and revert look like in the Graph?
Watching the Graph while you run these commands builds the right picture faster than any description. The faded dot after an amend is still reachable through git reflog for a while, which helps if you amend by mistake.
- Amend: the top dot is replaced. The count stays the same, the id changes, and the old dot fades out because no branch points to it any more.
- Revert: a new dot is added on top. Every older dot keeps its id, including the one being undone.
- Amend with nothing staged and
-m: only the message changes, but the id still changes, because the message is part of the commit. - Revert of a revert: the original change comes back as a third commit. History tells the whole story in order.
What should you check when an AI tool suggests these commands?
Read the command and ask which commit it touches. git commit --amend always means the last commit on the branch you are on. If you have switched branches since, that may be a different commit than the assistant expects.
Look for --force or -f in any push that follows an amend. That flag overwrites the remote. On a solo branch it is routine; on a shared main it can wipe out a teammate's work. Prefer --force-with-lease in real Git, which refuses if the remote moved since you last fetched.
If an assistant suggests git reset --hard to undo a commit that is already pushed, a revert is usually the better answer. Reset rewrites history the same way amend does, only further back.
Field notes
git commit --amendreplaces the last commit with one that includes what you staged.- Amend only when the fix belongs to the last commit and nobody else has it yet.
git revertundoes an older commit by adding a new commit that reverses it.- Revert keeps history intact, so it is safe for commits you have already shared.
Easy to get wrong
Amend uses the staging area. An unstaged edit stays out of the new commit, so the typo is still in history.
Force pushing a rewritten commit removes the old one from GitHub while teammates still have it. Revert adds history instead of replacing it.
Revert needs a commit id or a name such as HEAD~1, never the message text.
Questions people ask
Does amend change the commit id?
Yes, always. The id is calculated from the content, the message, the parent and the time, so any change gives a new id, even a message-only change.
Can I undo an amend?
Usually. git reflog lists where your branch pointed before the amend. git reset --hard <that id> puts it back, which the reset lesson covers.
Does revert delete the old commit?
No. The old commit stays in history. The revert is a new commit with the opposite change, so git log shows both.
Can I revert a merge commit?
Real Git can, with git revert -m 1 <id>, which tells it which parent to keep. It is easy to get wrong, so try it on a test branch first. The practice terminal refuses merge reverts.
Is git commit --amend the same as git commit --amend --no-edit?
In real Git, plain --amend opens the editor with the old message so you can change it. --no-edit skips the editor and keeps the message. The practice terminal has no editor, so it keeps the message either way.