Viewing History and Changes: log, diff and show
See exactly what changed with git diff and git diff --staged, explore history with git log options, inspect a commit with git show and find who changed a line with git blame.
On this page 12 sections
Introduction
Committing is only half of version control. The other half is understanding changes: what exactly did I just edit, what am I about to commit, and when did this line change? Git answers all of these questions, and reading its answers is a skill you will use daily — especially during code review.
- How to see unstaged and staged changes with git diff.
- How to read the lines of a diff.
- Useful git log options for exploring history.
- How to inspect one commit with git show and trace a line with git blame.
A Quick Status
Priya adds an “About me” section to index.html, below the first paragraph:
<h2>About me</h2> <p>I enjoy building small, fast websites.</p>The full git status output is helpful but long. git status --short gives a compact version:
git status --shortClick Run to see what this code prints.
Each line starts with two columns: the left one shows the staging area and the right one the working directory. M (a space then M) means “modified, not staged yet”. You will also see A for added, D for deleted, and ?? for untracked files.
Seeing Changes with git diff
git diff shows exactly what you changed in your working directory compared with the staging area — in other words, the changes you have not staged yet:
git diffClick Run to see what this code prints.
Reading a Diff
| Part of the diff | What it means |
|---|---|
| diff --git a/index.html b/index.html | The file being compared: a/ is the old version, b/ is the new one. |
| --- a/index.html and +++ b/index.html | Lines from the old file are marked with -, lines from the new file with +. |
| @@ -7,5 +7,7 @@ | A “hunk” header: this section starts at line 7 and covers 5 lines in the old file and 7 in the new one. |
| Lines starting with + | Added lines. |
| Lines starting with - | Removed lines (a changed line appears as one removal plus one addition). |
| Lines starting with a space | Unchanged context lines, shown so you can see where the change is. |
In a diff, you see the line - <h1>Hi, I'm Priya</h1> followed by + <h1>Hello! I'm Priya</h1>. What happened?
Staged Changes
Here is a detail that confuses many beginners. Stage the change, then run git diff again:
git add index.htmlgit diffClick Run to see what this code prints.
Nothing! That is because plain git diff only shows changes that are not staged. To see what is staged — exactly what your next commit will contain — add --staged:
git diff --stagedClick Run to see what this code prints.
Run git diff --staged just before every commit. It takes seconds and catches debugging code, typos and files you did not mean to include.
git commit -m "Add about section"Click Run to see what this code prints.
Exploring History
git log has many options. These are the ones you will use most:
git log --onelineClick Run to see what this code prints.
--stat adds a summary of which files changed, and a number like -1 limits how many commits are shown:
git log --stat -1Click Run to see what this code prints.
Put a file name after -- to see only the commits that touched that file:
git log --oneline -- style.cssClick Run to see what this code prints.
| Command | Shows |
|---|---|
| git log -p | Each commit together with its full diff |
| git log --author="Priya" | Only commits by a matching author |
| git log --since="2 weeks ago" | Only recent commits |
| git log --grep="contact" | Only commits whose message contains a word |
| git log --oneline --graph --all | A text diagram of every branch (lesson 7) |
Inspecting a Commit
git show displays a single commit: its details and its changes. You can name the commit by its ID, or relative to HEAD. HEAD means “the commit you are on now”, HEAD~1 means one commit before it, HEAD~2 two before, and so on:
git show --stat HEAD~1Click Run to see what this code prints.
Without --stat, git show prints the full diff of the commit. You can also compare any two commits directly, for example git diff 55024d8 3332d24.
Who Changed This Line?
git blame labels every line of a file with the commit, author and date that last changed it. Despite the name, it is not about blaming people — it is the fastest way to find the commit (and message) that explains why a line exists:
git blame index.htmlClick Run to see what this code prints.
Lines 10 and 11 come from the “Add about section” commit; the rest come from the first commit (the ^ marks the root commit).
You staged some changes and want to double-check exactly what will be committed. You run git diff but it prints nothing. What should you run instead?
Common Mistakes
- Thinking an empty git diff means there are no changes — staged changes need git diff --staged.
- Committing without looking at the diff first, then discovering leftover debugging code later.
- Getting stuck in the pager after git log or git diff — press q to quit.
- Using git blame to find someone to blame; use it to find the commit message that explains a change.
Frequently Asked Questions
HEAD is a pointer to the commit you currently have checked out — usually the latest commit on your current branch. HEAD~1 is its parent, HEAD~2 its grandparent, and so on.
Yes. VS Code’s Source Control panel, GitHub’s web interface and tools like git difftool show the same information side by side. The command-line format is still worth learning, because code review on GitHub uses the same + and - notation.
No. Git accepts any unique prefix, and seven characters is usually enough. Very large projects may show slightly longer short IDs to keep them unique.
Key Takeaways
- git diff shows unstaged changes; git diff --staged shows what your next commit will contain.
- In a diff, + marks added lines, - marks removed lines, and a changed line appears as both.
- git log options like --oneline, --stat, -p and -- <file> help you explore history.
- git show displays one commit; HEAD, HEAD~1 and HEAD~2 name commits relative to where you are.
- git blame shows which commit last changed each line of a file.
Summary
You can now see every change before and after you commit, and trace any line back to the commit that introduced it. Next comes the reassuring part of Git: undoing things. You will learn to discard edits, unstage files, fix your last commit and safely reverse mistakes.