GIT: Chapter 5 — Tracking Changes

Chapter 5 — Tracking Changes

5.1 Overview

Version control systems exist primarily to monitor and manage changes in files over time. In Git, change tracking is granular, explicit, and reversible. Every modification can be inspected, staged, committed, compared, reverted, or merged.

This chapter examines the internal workflow Git uses to track changes and the command set required to operate effectively within that workflow.

---

5.2 Git Change-Tracking Architecture

Git maintains three logical areas:

1. Working Directory

• The actual project files on disk

• Where editing, creation, and deletion occur

• Represents the current state of development

2. Staging Area (Index)

• Intermediate layer between working directory and repository

• Holds selected changes for the next commit

• Enables partial commits

3. Repository (HEAD)

• Permanent history storage

• Contains commits and metadata

• Represents last committed state

Conceptual flow

$$\text{Working Directory} \rightarrow \text{Staging Area} \rightarrow \text{Repository}$$

Understanding this tri-state model is critical for mastering Git.

---

5.3 File Lifecycle States

Every file in Git exists in one of several states:

State	Meaning
Untracked	File exists but Git is unaware
Unmodified	File tracked and unchanged
Modified	File changed but not staged
Staged	Changes prepared for commit
Committed	Stored in repository history

This lifecycle forms the operational backbone of Git.

---

5.4 Checking Repository Status

The primary diagnostic command is:

git status

Capabilities

• Lists modified files

• Shows staged vs unstaged changes

• Displays untracked files

• Indicates branch and divergence state

Short format

git status -s

Example output:

 M index.html
A  script.js
?? notes.txt

Interpretation:

• M (right column) → modified but unstaged

• A (left column) → staged addition

• ?? → untracked file

---

5.5 Viewing Differences

Git supports multiple diff comparisons.

1. Working directory vs staging

git diff

Shows unstaged changes.

---

2. Staging vs last commit

git diff --staged

Displays staged changes.

---

3. Between commits

git diff commit1 commit2

Useful for historical analysis.

---

4. Specific file diff

git diff file.txt

Provides targeted inspection.

---

5.6 Adding Changes to Staging

Add single file

git add file.txt

---

Add multiple files

git add file1 file2

---

Add all changes

git add .

---

Add tracked files only

git add -u

---

Interactive staging

git add -p

Allows chunk-level staging, supporting atomic commits.

---

5.7 Ignoring Files

Certain files should not be tracked (logs, binaries, environment configs).

.gitignore example

node_modules/
*.log
.env
build/

Key principles

• Pattern based

• Directory ignore supported

• Global ignore possible

---

5.8 Removing Files

Remove tracked file

git rm file.txt

Stages deletion.

---

Remove but keep locally

git rm --cached file.txt

Stops tracking without deleting disk file.

---

Remove directory

git rm -r folder/

Recursive removal.

---

5.9 Moving and Renaming Files

git mv old.txt new.txt

Combines rename and staging.

Git can also detect renames heuristically without this command, but explicit renaming improves clarity.

---

5.10 Committing Changes

Commit operation records staged changes.

git commit -m "message"

Best practices

• Atomic commits

• Imperative message style

• Clear intent

• One logical change per commit

---

Commit staged and tracked files

git commit -a -m "message"

Skips explicit add for tracked files.

---

5.11 Amending Commits

Modify last commit:

git commit --amend

Use cases:

• Fix message

• Add forgotten changes

⚠ Avoid amending pushed commits in shared repositories.

---

5.12 Viewing Commit History

Standard log

git log

---

Compact view

git log --oneline

---

Graph visualization

git log --graph --oneline --all

Displays branch topology.

---

5.13 Restoring Changes

Discard working directory changes

git restore file.txt

---

Unstage file

git restore --staged file.txt

---

Restore from commit

git restore --source=HEAD~1 file.txt

---

5.14 Advanced Change Tracking Concepts

Partial commits

• Enabled via patch mode

• Useful in refactoring scenarios

Whitespace control

• Git can ignore whitespace differences

Binary change detection

• Git stores full snapshot but compresses internally

Content-addressable storage

• Every blob identified via SHA hash

• Enables integrity verification

---

5.15 Practical Workflow Example

Edit files
↓
git status
↓
git diff
↓
git add selected changes
↓
git diff --staged
↓
git commit
↓
git log

This loop forms the daily development cycle.

---

5.16 Common Mistakes

Mistake	Impact
Blind git add .	Accidental commit of secrets
Large commits	Hard review
No .gitignore	Repository pollution
Amending shared commits	History rewrite conflicts

---

5.17 Summary

This chapter established the operational mechanics of Git change tracking:

• Working directory → staging → repository pipeline

• File lifecycle states

• Diff inspection strategies

• Selective staging

• Commit construction and amendment

• Restoration workflows

• History analysis

Mastery of change tracking transforms Git from a storage tool into a precise development instrument.