Undoing things
The mistake is two commits deep and someone else already built on top of it. Deleting it isn't as simple as it sounds.
Sahil confirms the typo — 4px should've been 24px — and your first instinct is the obvious one: go back to that commit and just fix it, like the mistake never happened.
Rachit stops you. "Wait — I pulled this morning to keep working on the footer links. If you rewrite that commit and I pull again, is my copy going to break?"
That's a real question, and the honest answer is: it depends entirely on how you undo it. Some ways of "going back and fixing it" are perfectly safe. One specific way is exactly the kind of thing that quietly wrecks a teammate's afternoon.
The habit already in the club's own records
Here's a detail worth noticing before touching a single command: the Board's own SETUP_LOG.md — the file tracking every organisational decision — is written so that nothing is ever deleted from it. When an earlier entry turns out to be wrong, the fix isn't to edit that entry into looking correct after the fact. It's to add a new, dated entry saying "correction to decision #52: ..." The old entry stays, visibly wrong, with the correction right there after it. Anyone reading the log from the top still gets the true sequence of what actually happened, including the mistake.
Once a commit has been shared — pushed, pulled, seen by someone else — it deserves the exact same treatment. Rachit already has commit 7d0c2e5 (the 4px typo) sitting on his own machine. If you quietly erase it from history and force everyone to catch up, you're tearing a page out of a logbook someone already copied. If instead you add a new commit that corrects it, everyone converges naturally — nobody's local copy is suddenly wrong.
Two verbs that sound similar and are not
reset — moves the branch pointer backward, rewrites what "happened"
The commits after the target still physically exist in the repository for a while (reflog can find them), but nothing points at them anymore. As far as anyone pulling from you is concerned, they never existed. This is the torn-out page.
revert — adds a new commit that undoes an old one
The mistake stays visible in history, exactly like the SETUP_LOG's uncorrected original entries. A brand new commit says, in effect, "commit 7d0c2e5 was wrong; here is the opposite of what it did." This is the addendum.
revert. Reserve reset for commits that exist only on your own machine, that nobody else has touched yet.
Fixing Sahil's typo the safe way
One new commit, sitting honestly on top of everything else, restoring --section-gap to 24px. Rachit pulls it the next time he syncs, and his footer-links work merges in on top with zero drama. The 4px mistake is still visible if anyone ever wonders "wait, why is there a revert commit here" — and the answer is right there in the message, same as it would be in the SETUP_LOG.
When you're genuinely the only one who's seen it
reset isn't dangerous by nature — it's dangerous specifically when other people already have the commit you're erasing. Used on your own unshared work, it's just a fast local undo, and it comes in three strengths depending on how much you want to keep:
| Flag | Branch pointer | Staging area | Working directory |
|---|---|---|---|
--soft | Moves back | Untouched — old changes stay staged | Untouched |
--mixed (default) | Moves back | Cleared to match new HEAD | Untouched — files keep their edits |
--hard | Moves back | Cleared | Cleared — files are rewritten on disk |
Say you make three small, messy local commits fixing the same typo three separate times before getting it right, and none of them have left your machine yet. git reset --soft HEAD~3 collapses all three back into a single staged change, ready to be committed properly as one clean commit — nobody but you ever has to know there were three attempts.
The net underneath all of this
Even reset --hard — the version that rewrites files on disk — isn't actually as final as it feels in the moment. Remember git reflog from the end of the last chapter: it remembers every commit your HEAD has ever pointed to on this machine, for about 90 days, regardless of whether a branch currently points at it.
That's the actual safety net underneath every "undo" operation in Git — as long as a commit was made at some point, on this machine, it's findable. The genuinely unrecoverable mistakes are almost always about files that were never committed in the first place.
The rest of the toolbox, briefly
| You want to... | Command |
|---|---|
| Throw away un-staged edits in one file | git restore file.css |
| Unstage a file but keep the edits | git restore --staged file.css |
| Change the message of your last (unshared) commit | git commit --amend |
| Add a forgotten file to your last (unshared) commit | git add file.css && git commit --amend --no-edit |
Crisis resolved, and cleanly. But now Rachit has a genuinely different kind of request: he wants to try a full visual redesign of the homepage — new colors, new layout, a real experiment — without risking the version the Board's already seen and approved. Reverting a mistake is one thing. Trying something that might not work out at all is a different problem, and it needs a different tool.