Why diffing matters in Git - Why It Works

Introduction

When you work on code or files, you often change things. Diffing helps you see exactly what changed between two versions. This makes it easier to find mistakes and understand updates.

When you want to check what changes you made before saving or sharing your work

When you need to review changes made by a teammate before merging them

When you want to find out why a bug appeared by comparing current and previous versions

When you want to confirm that your fixes or updates are correctly applied

When you want to track progress by seeing what was added or removed over time

Commands

This command shows the changes you made in your working directory compared to the last saved version (commit). It helps you see what is new, changed, or deleted before you save.

Terminal

git diff

Expected Output

diff --git a/example.txt b/example.txt

index e69de29..d95f3ad 100644

--- a/example.txt

+++ b/example.txt

@@ -0,0 +1,2 @@

+Hello world

+This is a new line

→

--staged - Show changes that are staged for the next commit

→

--name-only - Show only the names of changed files

This command compares the last commit with the one before it. It shows what changed between these two saved versions.

Terminal

git diff HEAD~1 HEAD

Expected Output

diff --git a/example.txt b/example.txt

index e69de29..d95f3ad 100644

--- a/example.txt

+++ b/example.txt

@@ -0,0 +1,2 @@

+Hello world

+This is a new line

This shows the changes you have marked to be saved (staged) but not yet committed. It helps you review what will be included in your next save.

Terminal

git diff --cached

Expected Output

diff --git a/example.txt b/example.txt

index e69de29..d95f3ad 100644

--- a/example.txt

+++ b/example.txt

@@ -0,0 +1,2 @@

+Hello world

+This is a new line

Key Concept

If you remember nothing else from this pattern, remember: diffing shows exactly what changed so you can understand and control your work.

Common Mistakes

Running git diff after committing changes

git diff by default shows changes not yet saved; after commit, it shows nothing new

Use git diff HEAD~1 HEAD to compare the last two commits instead

Not staging changes before using git diff --cached

git diff --cached shows only staged changes; if nothing is staged, it shows nothing

Use git add to stage changes before running git diff --cached

Confusing git diff output with full file content

git diff shows only lines added or removed, not the whole file, which can confuse beginners

Focus on lines starting with + (added) or - (removed) to understand changes

Summary

git diff shows changes in your working files compared to the last saved version.

git diff HEAD~1 HEAD compares the last two commits to see what changed between them.

git diff --cached shows changes staged for the next commit, helping review before saving.

Practice

1. What is the main purpose of using git diff in a project?

easy

A. To delete files from the repository

B. To create a new branch

C. To merge two branches automatically

D. To see the exact changes made between file versions

Solution

1. Step 1: Understand the function of git diff

   git diff shows differences between file versions or commits.

2. Step 2: Identify what git diff does not do

   It does not delete files, merge branches, or create branches.

3. Final Answer:

   To see the exact changes made between file versions -> Option D

4. Quick Check:

   Diffing = showing changes [OK]

Hint: Diff means showing changes between versions [OK]

Common Mistakes:

• Confusing diff with branch creation
• Thinking diff deletes files
• Assuming diff merges branches

2. Which of the following is the correct command to see unstaged changes in your working directory?

easy

A. git diff

B. git diff --staged

C. git status -s

D. git log

Solution

1. Step 1: Recall the meaning of git diff

   git diff shows unstaged changes in your working directory compared to the last commit.

2. Step 2: Understand other commands

   git diff --staged shows staged changes, git status -s shows status summary, and git log shows commit history.

3. Final Answer:

   git diff -> Option A

4. Quick Check:

   Unstaged changes = git diff [OK]

Hint: Use plain git diff for unstaged changes [OK]

Common Mistakes:

• Using git diff --staged for unstaged changes
• Confusing git status with diff output
• Using git log to see file changes

3. Given the following commands run in a git repository:

echo 'Hello' > file.txt
git add file.txt
echo 'World' >> file.txt
git diff

What will git diff show?

medium

A. The difference showing the addition of 'World' in file.txt

B. The entire content of file.txt

C. No output because all changes are staged

D. An error because file.txt is staged

Solution

1. Step 1: Analyze the commands

   First, 'Hello' is written and staged with git add. Then 'World' is appended but not staged.

2. Step 2: Understand what git diff shows

   git diff shows unstaged changes compared to the index (staged files). So it will show the addition of 'World'.

3. Final Answer:

   The difference showing the addition of 'World' in file.txt -> Option A

4. Quick Check:

   git diff = unstaged changes [OK]

Hint: git diff shows changes after last staging [OK]

Common Mistakes:

• Thinking git diff shows staged changes
• Expecting full file content output
• Assuming git diff errors on staged files

4. You ran git diff but it shows no output even though you edited a file. What is the most likely reason?

medium

A. You forgot to save the file after editing

B. You staged the changes with git add

C. You are on the wrong branch

D. The file is ignored by .gitignore

Solution

1. Step 1: Understand what git diff shows

   git diff shows unstaged changes in saved files.

2. Step 2: Consider why no changes appear

   If the changes are staged with git add, git diff shows no output because there are no unstaged changes.

3. Final Answer:

   You staged the changes with git add -> Option B

4. Quick Check:

   Staged changes = no unstaged diff output [OK]

Hint: Stage changes to clear unstaged diff output [OK]

Common Mistakes:

• Assuming staged changes show in git diff
• Thinking branch affects unstaged diff
• Confusing ignored files with unstaged changes

5. You want to review changes between two commits abc123 and def456. Which command correctly shows the differences?

hard

A. git diff --compare abc123..def456

B. git diff --staged abc123 def456

C. git diff abc123..def456

D. git diff --between abc123 def456

Solution

1. Step 1: Recall correct syntax for comparing commits

   The correct syntax uses two commit hashes separated by two dots: git diff abc123..def456.

2. Step 2: Identify invalid options

   git diff --staged abc123 def456 is invalid syntax, and options with --between or --compare do not exist.

3. Final Answer:

   git diff abc123..def456 -> Option C

4. Quick Check:

   Commit range uses two dots [OK]

Hint: Use two dots between commits for diff [OK]

Common Mistakes:

• Using git diff --staged for commit diffs
• Adding unsupported flags like --between
• Confusing diff syntax with log syntax