Viewing History and Undoing Changes

Now that you can create commits, this fourth chapter of the Git and GitHub for Beginners series teaches you to read them and — more importantly — to undo things safely. Undoing is not one command but a small decision tree: what you are undoing and where it currently lives decides which command fits.

Reading history with git log

git log prints commits newest first, but its format is completely adjustable. The default verbose view is great for exploring; once you know what you are looking for, compact formats are faster to scan.

You can also filter: git log --since="2 weeks ago", git log --grep="menu", or git log -- index.html to list only commits that touched one path.

Zooming in with show and diff

Where log summarises history, show opens one commit: its message, metadata and full diff. Between snapshots, plain git diff answers a different question — what have I changed since I last staged? The output is a unified diff: context lines prefixed with a space, removed lines with -, added lines with +. Learn to read it and you can review any change on any machine.

Undoing uncommitted changes

The scariest-sounding undo is actually the most common and the simplest, because nothing is committed yet:

• Discard edits in a file — git restore <file> copies the last committed version back over your working copy.
• Unstage a file but keep the edits — git restore --staged <file> moves it out of the next commit without touching your work.
• Not sure? Run git status and git diff first. Nothing here affects commits that already exist.

Undoing commits you have already made

Once a commit exists the options widen, and the right one depends on whether anyone else has seen it. Three tools cover almost every case:

The golden rule behind that table: never rewrite history that other people have already pulled. Revert is always safe; reset and amend belong to commits only you have. You will practise all three in Correcting History: Reset, Revert and Rebase.

Recovering from a mistake: the reflog

If you reset too far or check out an old state and panic, take a breath. Git keeps a safety net called the reflog (reference log) that records where your branch pointer has been for roughly 90 days. git reflog lists those positions with hashes; finding the commit you lost and running git switch -c rescue <hash> brings it back on a new branch. As long as the commit was ever made, it is almost never truly gone.

git log --oneline -5

Expected output:

a1b2c3d Add homepage and update the menu prices
9f8e7d6 Save work in progress on the contact form
4c3b2a1 Fix the broken link in the footer
7e6d5c4 Style the navigation bar
b2a1f0e Initial commit

git diff -- bakery-menu.txt

Expected output:

diff --git a/bakery-menu.txt b/bakery-menu.txt
index 6c1a2f3..9ab4de1 100644
--- a/bakery-menu.txt
+++ b/bakery-menu.txt
@@ -1,3 +1,3 @@
 Sourdough loaf
-Croissant: Rs. 40
+Croissant: Rs. 45
 Chocolate cake

git restore --staged bakery-menu.txt
git status --short

Expected output:

M bakery-menu.txt
A contact.html

Common mistakes

• Running git restore without --staged when they meant to unstage — without the flag it discards the file's edits. Check status first.
• Using git reset --hard as a first reaction — it throws work away silently; try --soft or status/diff before hard resets.
• Amending a commit that is already pushed — teammates' clones reject the rewritten history and the branch diverges.
• Reading the default log output and giving up — start with --oneline and add detail only when you need it.
• Assuming an old commit is deleted when it leaves the branch — it usually stays reachable through the reflog until it eventually expires.

Practice checklist

1. Run git log --oneline in your practice repo and identify the hash, message and order of each commit.
2. Change a committed file without staging it and read git diff until the plus and minus lines make sense.
3. Stage that change, then undo the staging with git restore --staged and confirm the edit is still in your file.
4. Commit a small change, then practise git commit --amend to improve its message before pushing anywhere.
5. Run git reflog and find the hash of your most recent commit listed there.

What's next?

Single-track history is about to become a choose-your-own-adventure. Continue to Branching and Merging to learn how Git copies your entire project with one command.