Lesson 4 of 30

Commits and History

Q: What makes a commit message actually useful six months later, and how does that connect to how git log walks history under the hood?

A strong answer covers: Explains git log walks parent pointers backward from a starting commit (usually HEAD); Connects that to why --all matters — commits unreachable from HEAD won't show without it; Gives concrete criteria for a good message: what changed and briefly why, not just 'fix' or 'update'; Mentions practical payoff: git log --grep, git blame, or bisect all depend on messages/structure being meaningful.

Reading git log like it actually matters, what's really inside a commit, and why the message you write today is a message future-you has to trust.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Commits and History

What interviewers actually ask about this, and what a strong answer has to cover.

What makes a commit message actually useful six months later, and how does that connect to how git log walks history under the hood?

A strong answer covers

Explains git log walks parent pointers backward from a starting commit (usually HEAD)
Connects that to why --all matters — commits unreachable from HEAD won't show without it
Gives concrete criteria for a good message: what changed and briefly why, not just 'fix' or 'update'
Mentions practical payoff: git log --grep, git blame, or bisect all depend on messages/structure being meaningful

Likely follow-ups

You run plain git log and a commit you know exists doesn't show up. What's the most likely reason, and how do you find it?
What's structurally different about a merge commit compared to a normal commit, and how does --graph make that visible?
If you amend a commit's message without touching any file content, does the commit hash change? Why?

Practice these with the AI interviewer →

The plain-language idea

A commit is a small, real object with four pieces: a pointer to a tree (the full snapshot), a pointer to its parent commit (or parents, for a merge), an author (name, email, timestamp), and a message. That parent pointer is the entire mechanism behind history — git log doesn't consult some separate index of "what happened when," it just starts at HEAD and walks the chain of parent hashes backward, one commit at a time.

git log in its default form is verbose and rarely what you want day-to-day. The flags you'll actually reach for compress it into something scannable:

--oneline — one line per commit: short hash + message.
--graph — draws the branch/merge topology as ASCII lines alongside the log.
--stat — shows which files changed and by how many lines, per commit.

See it in a real thing: reading history that actually branched

$ git log --oneline --graph --all
* f3a9c21 (HEAD -> main) merge feature/search into main
|\
| * 8b2e410 (feature/search) add debounced search input
| * 1c7d9aa wire search API to results list
* | d4e8f01 fix flaky date formatting test
|/
* 92a01bc initial commit

Read bottom to top: one initial commit, then history splits (92a01bc has two children), work happens in parallel on main and feature/search, and f3a9c21 is a merge commit — it has two parents, which is why the graph lines rejoin there.

--stat on a single commit shows the shape of the change without the full diff:

$ git log -1 --stat 8b2e410
commit 8b2e4108f3a9c21...
Author: Adesh Shukla <shuklaadesh7@gmail.com>
Date:   Tue Sep 8 14:22:03 2026 +0530

    add debounced search input

 components/SearchBox.tsx | 34 ++++++++++++++++++++++++++++++----
 lib/hooks/useDebounce.ts | 12 ++++++++++++
 2 files changed, 42 insertions(+), 4 deletions(-)

And cat-file on that same hash confirms it's exactly the object shape from the mental-model lesson — tree, parent, author, message:

$ git cat-file -p 8b2e410
tree 4fa8c7...
parent 1c7d9aa...
author Adesh Shukla <shuklaadesh7@gmail.com> 1757324523 +0530
committer Adesh Shukla <shuklaadesh7@gmail.com> 1757324523 +0530

add debounced search input

Nothing about the message is enforced — Git will happily accept "fix" or "wip" as a commit message. But six months from now, git log --oneline is the only thing a teammate (or you) sees before deciding whether a commit is relevant to the bug they're chasing. A message that says what changed and, briefly, why — "add debounced search input" rather than "update SearchBox" — is the difference between git log --grep actually finding the right commit and someone opening ten diffs by hand.

What people usually miss

Watch out

The commit hash is computed from the message, not the other way around. Editing a commit message after the fact (git commit --amend) produces a brand new hash — it's a genuinely different commit object, not the same one with a field updated.
A merge commit has two parents, not one. That's the entire reason --graph shows lines rejoining — git log is following both parent pointers from that single commit backward.
git log only shows commits reachable from where you're looking. Run it with no arguments and you see history from HEAD backward — commits on a branch you haven't checked out, or that nothing points to anymore, won't appear without --all or naming that branch explicitly.

The genealogy: a linked list with a payload

A commit's parent pointer makes history a singly-linked list — the same data structure, just with a full snapshot and metadata riding along at each node instead of a bare value. Walking git log backward is identical in shape to walking any linked list by following .next (here, .parent) until you run out of nodes.