# Git Adventures — Part 2: When Git Starts Judging Your Decisions
In Part 1, everything was clean. Repository created. Project initialized. Branches created. Team motivated.
That illusion lasted exactly one day.
Because on Day 2, the team learned an important truth: Writing code is easy. Understanding history is hard.
And Git remembers everything.
Chapter 1 — The Calm Before the Debugging Storm
Amaresh notices something feels wrong after pulling updates. A feature that worked yesterday is broken. When did this happen?
He opens the timeline:
git log --oneline
Output:
a3f9c2b Add authentication flow
9d1a2e4 Fix validation issue
c81be77 Initial setup
Each commit shows a short hash (abbreviated commit ID) and message.
When you need the full commit ID:
git log
Or to just grab HEAD’s full ID:
git rev-parse HEAD
Output:
a3f9c2b7d8e9f0a1b2c3d4e5f6g7h8i9
Pro tip: Use git log --oneline -n 20 to see only the last 20 commits. Saves scrolling through months of history.
The gotcha: git log shows commits in reverse chronological order (newest first). If you’re looking for when something broke, scroll down, not up.
Commit IDs are your time machine. They allow precise navigation through Git history—and they’re immutable. The same commit ID always points to the exact same code, forever.
Chapter 2 — Understanding What Actually Changed
Amaresh needs to see exactly what was changed. Not just which files, but which lines.
git diff
Output:
diff --git a/auth.js b/auth.js
index 1a2b3c4..5d6e7f8 100644
--- a/auth.js
+++ b/auth.js
@@ -12,7 +12,7 @@
function validateToken(token) {
- if (token.length < 32) {
+ if (token.length < 16) {
return false;
}
Git highlights removed lines in red (with -) and added lines in green (with +).
Compare two branches:
git diff main feat/authentication
This shows all changes in feat/authentication that aren’t in main.
Compare two commits:
git diff a3f9c2b 9d1a2e4
See only filenames (not the code):
git diff --name-only main feat/authentication
See file statistics:
git diff --stat main feat/authentication
Output:
auth.js | 15 ++++++++++++---
utils.js | 8 ++------
2 files changed, 14 insertions(+), 9 deletions(-)
The gotcha: git diff with no arguments shows unstaged changes only. If you’ve already run git add, you won’t see those changes. Use git diff --staged to see staged changes.
Chapter 3 — Inspecting a Single Decision
Johnny broke something three commits ago. Now Amaresh needs to see exactly what that commit changed.
git show a3f9c2b
Output:
commit a3f9c2b7d8e9f0a1b2c3d4e5f6g7h8i9
Author: Johnny <[email protected]>
Date: Wed Mar 24 14:32:15 2026 +0530
Add authentication flow
diff --git a/auth.js b/auth.js
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/auth.js
@@ -0,0 +1,45 @@
+function authenticate(user, password) {
...
git show displays:
- Author — who made the change
- Date — when it was committed
- Message — the commit description
- Full diff — every line added/removed
See just the commit message:
git show a3f9c2b --format=fuller
Use with current HEAD:
git show HEAD
This is your bug detective tool. When you find a broken line, you can track exactly when it was added and by whom.
The gotcha: If a commit only renamed a file without changing it, git show will say “similarity index 100%” but show no actual changes. The file content is identical.
Chapter 4 — The Unexpected Urgent Task
Danny has been working on a feature for hours. Code is half-written, tests are incomplete. Then a critical production bug appears, and he must switch branches immediately.
He can’t commit incomplete work (it breaks the build). He can’t lose his changes. So he uses:
git stash
This saves all changes to a temporary location and resets the working directory to the last commit.
git checkout hotfix/critical-bug
# Fix the bug, commit, merge back to main
git checkout feat/incomplete-feature
Now he gets his incomplete work back:
git stash pop
But there’s a problem: He had created a new file (utils.js) that hadn’t been staged. After stashing and popping, the file is gone.
That’s because git stash by default only saves tracked files (files Git already knows about). New files are left behind.
The solution:
git stash -u
The -u (or --include-untracked) flag tells Git to stash everything, including brand new files.
Better yet, use this to be safe:
git stash -u -m "WIP: authentication feature with new utils"
The -m flag lets you label the stash so you remember what’s in it.
View all stashes:
git stash list
Output:
stash@{0}: WIP: authentication feature with new utils
stash@{1}: WIP: fixing typo in validator
stash@{2}: On main: saving work
Pop a specific stash:
git stash pop stash@{1}
Delete a stash without popping:
git stash drop stash@{0}
Clear all stashes (⚠️ dangerous):
git stash clear
The gotcha: git stash pop removes the stash after applying it. If the pop fails (merge conflict), the stash stays safe. But if it succeeds and you later realize you needed it, it’s gone. Use git stash apply instead if you want to keep the stash around.
Chapter 5 — The First Real Merge Conflict
Johnny finishes his service-layer feature. Ronaldo finishes his database optimization feature. Both edited the same file. Johnny tries to merge Ronaldo’s branch:
git merge feat/service-layer
Git responds:
Auto-merging api.js
CONFLICT (content): Merge conflict in api.js
Automatic merge failed; fix conflicts and then commit the result.
He opens api.js and sees:
function handleRequest(req, res) {
<<<<<<< HEAD
// Ronaldo's code (database optimization)
const data = db.query(req.id);
res.send(data);
=======
// Johnny's code (service layer)
const service = new Service();
const data = service.fetch(req.id);
res.send(data);
>>>>>>> feat/service-layer
}
The conflict markers show:
-
<<<<<<< HEAD— start of current branch (what you have now) -
=======— divider -
>>>>>>> feat/service-layer— end of incoming branch (what you’re merging in)
Johnny must decide: Keep Ronaldo’s code? Keep his own? Use both?
He decides to use his service layer but call the optimized query:
function handleRequest(req, res) {
const service = new Service();
const data = service.fetch(req.id); // Johnny's code
// Ronaldo's optimization is now inside service.fetch()
res.send(data);
}
Now resolve the conflict:
git add api.js
git commit -m "Merge feat/service-layer: resolve conflict in api.js"
Tools to help with conflicts:
# See which files have conflicts
git diff --name-only --diff-filter=U
# Use a visual merge tool (if configured)
git mergetool
Abort a merge if you’re not ready:
git merge --abort
The gotcha: Merge conflicts are not errors—they’re Git asking you to make a decision. A merge with zero conflicts often means someone’s code got silently overwritten. Conflicts are actually good; they force you to think.
Chapter 6 — Fetch vs Pull vs Merge (The Confusion Explained)
Many developers use these terms interchangeably. They’re not.
git fetch — Downloads changes from remote, but doesn’t integrate them:
git fetch origin
This updates your local tracking branches (origin/main, origin/feat/something) but leaves your local main branch untouched.
git merge — Combines histories:
git merge origin/main
This integrates the remote changes into your current branch.
git pull — Fetch + merge in one command:
git pull origin main
Equivalent to:
git fetch origin
git merge origin/main
Why does this matter?
The professional workflow is:
git fetch origin # Download changes
git log main origin/main # Inspect what changed
git merge origin/main # Merge when ready
Why? Because git pull can silently create merge commits you didn’t expect. Fetching first lets you review changes before integrating them.
Comparison table:
| Command | Changes local branch? | Creates merge commit? | Safe to use blindly? |
|---|---|---|---|
git fetch |
❌ No | ❌ No | ✅ Yes |
git merge |
✅ Yes | ✅ Maybe | ⚠️ Only if branches are synced |
git pull |
✅ Yes | ✅ Usually | ⚠️ Can surprise you |
The gotcha: git pull can create a merge commit automatically. If you’re trying to keep a clean history, this is annoying. Use git pull --rebase to rebase instead of merge (we’ll cover rebase in Part 3).
Chapter 7 — Undoing Mistakes Properly
Mistakes happen. Git gives you three different ways to undo, and they each do something different.
Mistake Type 1: “I edited a file but haven’t staged it”
Amaresh edited config.js but realizes it’s wrong. He hasn’t run git add yet.
git restore config.js
This overwrites config.js with the version from the last commit. Changes are gone.
Old syntax (still works):
git checkout config.js
Mistake Type 2: “I staged changes I shouldn’t have”
Amaresh ran git add . and included config.js accidentally. He hasn’t committed yet.
git restore --staged config.js
This unstages the file. The file still exists in your working directory with all changes intact—only the staging is removed.
Undo all staged changes:
git restore --staged .
Mistake Type 3: “I committed something wrong but haven’t pushed”
Johnny committed buggy code. It’s in his local history but not on GitHub yet.
git reset HEAD~1
This moves the branch pointer back one commit. The buggy commit disappears from history. But the files are still in your working directory with changes intact.
# Edit the files, fix the bug
git add .
git commit -m "Fixed version of that commit"
The variants:
git reset --soft HEAD~1 # Undo commit, keep changes staged
git reset --mixed HEAD~1 # Undo commit, keep changes unstaged (default)
git reset --hard HEAD~1 # Undo commit, DISCARD all changes (⚠️ dangerous)
The gotcha: git reset --hard is permanent. Your code is deleted. If you haven’t pushed, you can use git reflog to recover, but it’s nerve-wracking. Default to --mixed or --soft.
Mistake Type 4: “I committed bad code that’s already pushed”
Ronaldo pushed a commit that broke production. He can’t just git reset because others have already pulled his changes. Rewriting history would break their local repos.
git revert a3f9c2b
This creates a new commit that undoes the changes from commit a3f9c2b. Git history stays intact. Everyone can pull the revert safely.
Output:
[main 7f8e9d0] Revert "Add broken authentication"
1 file changed, 2 deletions(-)
Now the repo is fixed, and history shows exactly what happened.
Compare the three approaches:
| Situation | Command | Creates new commit? | Safe to push? | Reversible? |
|---|---|---|---|---|
| Unstaged file mess | git restore |
❌ No | ✅ N/A | ❌ Deleted |
| Staged file mess | git restore --staged |
❌ No | ✅ N/A | ✅ Still in working dir |
| Wrong local commit | git reset |
❌ No | ❌ Rewrites history | ✅ Use git reflog
|
| Pushed bad commit | git revert |
✅ Yes | ✅ Safe | ✅ Fully reversible |
The Safety Net: git reflog
Here’s the command nobody tells you about until you need it.
Amaresh ran git reset --hard and deleted code he wanted. Is it gone forever?
git reflog
Output:
a3f9c2b HEAD@{0}: reset: moving to HEAD~1
9d1a2e4 HEAD@{1}: commit: Add authentication flow
c81be77 HEAD@{2}: commit: Initial setup
The reflog shows every place HEAD has been. He can recover:
git reset --hard HEAD@{1}
The safety net catches you. Use this when you panic after a hard reset.
Quick Reference Cheat Sheet
| Problem | Command | Result |
|---|---|---|
| View commit history | git log --oneline |
Shows last commits |
| See what changed | git diff |
Shows unstaged changes |
| See staged changes | git diff --staged |
Shows changes ready to commit |
| Compare branches | git diff main feat/new |
Shows differences |
| Inspect a commit | git show <commit-id> |
Shows commit details |
| Save work temporarily | git stash -u -m "label" |
Saves including untracked files |
| Restore saved work | git stash pop |
Applies last stash |
| Download remote changes | git fetch origin |
Safe, doesn’t merge |
| Download + merge | git pull |
Fetch + merge in one |
| Undo unstaged changes | git restore <file> |
Discards edits to file |
| Unstage changes | git restore --staged <file> |
Keeps changes, removes from staging |
| Undo last commit (local) | git reset HEAD~1 |
Moves branch back |
| Undo last commit (pushed) | git revert <commit-id> |
Creates undo commit |
| Undo hard reset | git reflog |
Shows all HEAD positions |
By the end of Day 2, the team realized something important:
Git doesn’t judge you for making mistakes. It judges you for not knowing how to recover from them.
Master these commands, and you’ll never panic:
-
git log+git show— understand what happened -
git diff— see exactly what changed -
git stash— escape from immediate problems -
git restore/git reset/git revert— fix them the right way -
git reflog— panic button
End of Part 2
The team learned:
-
git log --oneline— time machine for commits -
git diff— see changes precisely -
git show— inspect a single commit -
git stash -u— save incomplete work - Merge conflicts — human decisions required
-
git fetchvsgit pull— when to use which -
git restorevsgit resetvsgit revert— right tool for the job -
git reflog— the safety net
What’s Coming in Part 3
- Rebase — rewriting history (safely)
- Interactive rebase — rearranging commits
- Cherry-pick — copying specific commits
- Tagging — marking important versions
- Rebasing vs Merging — the great Git debate
