Reading diffs and the log

git diff with no arguments compares your working tree against the staging area — the changes you have NOT staged yet. This is the most common diff and the one beginners misread. It does not show everything you changed since the last commit; it shows only what is still unstaged:

git diff

Once you git add a change, it disappears from plain git diff (it is now staged) and you need a different variant to see it. That surprise — “I edited the file, why is the diff empty?” — almost always means you already staged it.

Three diff variants compare three different pairs of snapshots. Pick by what you want to see:

git diff            # working tree vs index  → unstaged changes
git diff --staged   # index vs HEAD          → what a commit would record (also --cached)
git diff HEAD       # working tree vs HEAD    → all changes since last commit (staged + unstaged)

HEAD is the latest commit on your current branch. git diff --staged is the one to run right before committing — it shows exactly what the commit will contain, nothing more. git diff HEAD is the big picture: everything different from the last commit regardless of staging.

A unified diff is read as a set of hunks, each with a header and three kinds of lines. Here is one hunk:

@@ -12,6 +12,7 @@ function login(user) {
   const token = sign(user);
-  return token;
+  log.debug("issued token");
+  return token;
 }

The @@ -12,6 +12,7 @@ header is the map: -12,6 means “the old file, starting at line 12, spanning 6 lines”; +12,7 means “the new file, starting at line 12, spanning 7 lines”. After it: a leading space is unchanged context, a - is a line removed, a + is a line added. A modified line shows as a - (old) immediately followed by a + (new). Read top to bottom and you reconstruct the edit exactly.

git log lists history; flags turn a wall of text into a readable map. The raw log is verbose, so seniors almost always shape it:

git log                            # full entries: hash, author, date, message
git log --oneline                  # one compact line per commit
git log --oneline --graph --all --decorate   # ASCII branch graph across all branches

--oneline collapses each commit to a short hash plus subject; --graph draws the branch/merge structure; --all includes every branch, not just the current one; --decorate shows which branch and tag names point where. This combination is the single most useful way to see “what is the shape of this repo’s history?”

git show inspects one commit in full — its metadata plus its diff. When log tells you which commit you care about, show tells you what it did:

git show <commit>         # that commit's message and its full diff
git log -p                # every commit's full diff, newest first
git log --stat            # per-commit summary: files touched, +/- line counts

git show abc1234 prints the author, date, message, and the exact hunks that commit introduced — the fastest way to answer “what did this commit actually change?”