Learn Git - Comparing Changes & Inspecting Code

#Introduction

In episode 4 you started building a clean commit history. As the history grows, critical questions arise: what exactly changed in this commit? Does the staging area match expectations? Who wrote this problematic line of code?

This episode is investigation training. Three commands — git diff, git show, and git blame — are the detective tools you will use nearly every day, whether during code review, debugging, or figuring out why a line of code exists.

#Comparing Differences with git diff

#git diff: Working Directory vs Staging Area

git diff without arguments compares the working directory with the staging area — showing changes that have not been staged yet.

git diff
diff --git a/index.html b/index.html
--- a/index.html
+++ b/index.html
@@ -1 +1 @@
-<h1>Halo Dunia</h1>
+<h1>Halo, Git!</h1>

How to read the diff output:

• The --- line is the old version, the +++ line is the new version.
• Lines marked - were deleted, lines marked + were added.

#git diff --staged: Staging Area vs Last Commit

To see changes that have been staged, use git diff --staged (synonym: --cached):

git diff --staged
git diff --cached

Meanwhile, git diff HEAD compares both at once: the entire difference between the working tree and the last commit — the combined staged and unstaged changes.

#Comparing Two Commits

To see the difference between any two commits, provide two hashes:

git diff 9c4a2d6e b8e1f3a7

This command shows all changes from the first commit to the second — very useful during code review to see what changed in a single pull request.

#Map of git diff Comparisons

To avoid confusion, the summary below orders the comparisons from the most "fresh" to the most historical:

#Inspecting Commit Details with git show

git show <hash> displays one commit in full: metadata (author, date, message) plus the diff of changes it introduced. This is the fastest window into understanding a commit's content.

git show b8e1f3a7
commit b8e1f3a7
Author: Arman Dwi Pangestu
    feat: tambah halaman login

git show HEAD shows the last commit; git show HEAD~1 shows the commit one before HEAD. Without a hash argument, git show displays the currently active commit (HEAD).

#Identifying Authors with git blame

git blame <file> answers the question: who changed this line, when, and in which commit?

git blame login.js
b8e1f3a7 (Arman Dwi Pangestu 2026-08-01 10:22) function login(user) {
b8e1f3a7 (Arman Dwi Pangestu 2026-08-01 10:22)   if (!user.password) {
7a2c9d1e (Rina Sari 2026-07-28 14:05)   throw new Error("password wajib");

Each line is marked with the commit hash, author, date, and the line's content. Use git blame when you find a bug: trace the commit that introduced the problematic line, then look at the change context at that time — often the reason becomes clear.

#When to Use Which

These three commands complement each other for different scenarios:

• Before committing — git diff to check the raw changes, then git diff --staged to make sure the staging area is free of anything unwanted.
• During code review — git diff <c1> <c2> to see what changed across the whole pull request; git show <hash> to assess one commit in depth.
• While debugging — git blame <file> finds the commit that introduced the bug, then git show <hash> opens the full change context of that commit.

#Closing

Episode 5 recap:

• git diff compares the working directory vs staging area; git diff --staged for already staged changes.
• git diff HEAD combines both; git diff <commit1> <commit2> compares two commits.
• git show <hash> opens the full details of one commit.
• git blame <file> traces the author and origin of every line of code.

In episode 6 we enter the most anticipated new chapter: branching — understanding that a branch is just a lightweight pointer, creating and switching branches with git switch, and renaming and deleting branches. With that, you are ready to work on features without disturbing the main work. See you there!