DEV Community

Cover image for # Git Adventures --- Part 2: When Git Starts Judging Your Decisions
Amaresh Pati
Amaresh Pati

Posted on

# Git Adventures --- Part 2: When Git Starts Judging Your Decisions

#beginners #devjournal #git #tutorial

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
Enter fullscreen mode Exit fullscreen mode

Output:

a3f9c2b Add authentication flow
9d1a2e4 Fix validation issue
c81be77 Initial setup
Enter fullscreen mode Exit fullscreen mode

Each commit shows a short hash (abbreviated commit ID) and message.

When you need the full commit ID:

git log
Enter fullscreen mode Exit fullscreen mode

Or to just grab HEAD's full ID:

git rev-parse HEAD
Enter fullscreen mode Exit fullscreen mode

Output:

a3f9c2b7d8e9f0a1b2c3d4e5f6g7h8i9
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
    }
Enter fullscreen mode Exit fullscreen mode

Git highlights removed lines in red (with -) and added lines in green (with +).

Compare two branches:

git diff main feat/authentication
Enter fullscreen mode Exit fullscreen mode

This shows all changes in feat/authentication that aren't in main.

Compare two commits:

git diff a3f9c2b 9d1a2e4
Enter fullscreen mode Exit fullscreen mode

See only filenames (not the code):

git diff --name-only main feat/authentication
Enter fullscreen mode Exit fullscreen mode

See file statistics:

git diff --stat main feat/authentication
Enter fullscreen mode Exit fullscreen mode

Output:

auth.js     | 15 ++++++++++++---
utils.js    |  8 ++------
 2 files changed, 14 insertions(+), 9 deletions(-)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Output:

commit a3f9c2b7d8e9f0a1b2c3d4e5f6g7h8i9
Author: Johnny <johnny@company.com>
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) {
...
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Use with current HEAD:

git show HEAD
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Now he gets his incomplete work back:

git stash pop
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

The -m flag lets you label the stash so you remember what's in it.

View all stashes:

git stash list
Enter fullscreen mode Exit fullscreen mode

Output:

stash@{0}: WIP: authentication feature with new utils
stash@{1}: WIP: fixing typo in validator
stash@{2}: On main: saving work
Enter fullscreen mode Exit fullscreen mode

Pop a specific stash:

git stash pop stash@{1}
Enter fullscreen mode Exit fullscreen mode

Delete a stash without popping:

git stash drop stash@{0}
Enter fullscreen mode Exit fullscreen mode

Clear all stashes (⚠️ dangerous):

git stash clear
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Git responds:

Auto-merging api.js
CONFLICT (content): Merge conflict in api.js
Automatic merge failed; fix conflicts and then commit the result.
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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);
}
Enter fullscreen mode Exit fullscreen mode

Now resolve the conflict:

git add api.js
git commit -m "Merge feat/service-layer: resolve conflict in api.js"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Abort a merge if you're not ready:

git merge --abort
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This integrates the remote changes into your current branch.

git pull — Fetch + merge in one command:

git pull origin main
Enter fullscreen mode Exit fullscreen mode

Equivalent to:

git fetch origin
git merge origin/main
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This overwrites config.js with the version from the last commit. Changes are gone.

Old syntax (still works):

git checkout config.js
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 .
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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(-)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Output:

a3f9c2b HEAD@{0}: reset: moving to HEAD~1
9d1a2e4 HEAD@{1}: commit: Add authentication flow
c81be77 HEAD@{2}: commit: Initial setup
Enter fullscreen mode Exit fullscreen mode

The reflog shows every place HEAD has been. He can recover:

git reset --hard HEAD@{1}
Enter fullscreen mode Exit fullscreen mode

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 fetch vs git pull — when to use which
  • git restore vs git reset vs git 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

Top comments (0)