Debugging Best Practices

The Hook (The "Byte-Sized" Intro)

Good debugging is less guessing, more narrowing. Random console.log statements are amateur hour. A systematic Git-powered approach narrows thousands of lines to the exact commit and line that caused the problem. Reproduce → Narrow → Identify → Verify → Document. Five steps. Works every time.

📖 What are Debugging Best Practices?

A systematic, repeatable workflow for using Git's history tools to find, understand, and fix bugs.

Conceptual Clarity

The RNIVD framework:

Step	Action	Tool
R - Reproduce	Confirm the bug is real	Manual testing
N - Narrow	Find the timeframe/version	`git log`, `git bisect`
I - Identify	Find the exact commit + line	`git blame`, `git log -S`
V - Verify	Confirm the fix works	`git stash`, tests
D - Document	Record what happened	Commit message, issue tracker

Choosing the right tool:

Situation	Best Tool
"What changed recently?"	`git log --oneline -20`
"When did this line appear?"	`git log -S "string"`
"Who wrote this?"	`git blame -w file.js`
"Which commit broke things?"	`git bisect`
"Where is this string used?"	`git grep "string"`
"What changed in this release?"	`git diff v1.0..v2.0`

Real-Life Analogy

Debugging with Git is like detective work: reproduce the crime (reproduce the bug), narrow the timeline (which commits?), identify the suspect (which change?), verify with evidence (does fixing it work?), and close the case (document in the commit message).

Visual Architecture

flowchart LR R["🔁 Reproduce"] --> N["🔍 Narrow"] N --> I["🎯 Identify"] I --> V["✅ Verify"] V --> D["📝 Document"] style R fill:#2d1b1b,stroke:#e94560,color:#e94560 style I fill:#1a1a2e,stroke:#ffd700,color:#ffd700 style D fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Speed: Systematic approach is faster than random guessing.
Precision: Git tools narrow to the exact commit and line.
Learning: Understanding why bugs happen prevents recurrence.
Documentation: Good commit messages help future debugging.

Code

bash

# ─── STEP 1: Reproduce ───
# Run the failing test / trigger the bug manually

# ─── STEP 2: Narrow ───
# Check recent changes
git log --oneline -20

# When was it last working?
git log --since="1 week ago" --oneline

# Binary search for the breaking commit
git bisect start HEAD v1.0.0
git bisect run npm test

# ─── STEP 3: Identify ───
# Found the breaking commit: abc1234
git show abc1234               # See what changed
git blame -w src/auth.js -L 40,50  # Who wrote this line?

# ─── STEP 4: Verify ───
# Fix the issue, run tests
npm test
git diff                       # Review your fix

# ─── STEP 5: Document ───
git commit -m "fix: resolve auth timeout caused by missing null check

The validateToken function did not handle expired tokens,
introduced in abc1234. Added null check and expiry validation.

Fixes #167"

Key Takeaways

Follow RNIVD: Reproduce → Narrow → Identify → Verify → Document.
Use the right tool for each step — bisect to narrow, blame to identify.
Document the fix in a descriptive commit message — future you will thank you.
A systematic approach is always faster than guessing.

Interview Prep

Q: What is your process for debugging a bug using Git? A: Reproduce the bug, narrow the timeframe using git log or git bisect, identify the exact commit/line with git blame or git log -S, verify the fix with tests, and document the root cause in the commit message.
Q: When would you use git bisect vs git blame? A: git bisect when you know the bug exists now but not when it was introduced — it binary-searches for the breaking commit. git blame when you can see the problematic line and want to know who changed it and why.
Q: Why is documentation important in the debugging workflow? A: A well-written commit message with the root cause and fix helps future developers (including yourself) understand why the change was made. It also links to the issue tracker for context.