DEV Community: Rajat

What I got wrong about Git for years

Rajat — Sat, 27 Jun 2026 08:10:00 +0000

I used Git for years before I actually understood it.

I could commit, push, pull, and make a branch. I could copy-paste my way out of most messes. But I didn't have a model in my head for what Git was doing. So every time something went sideways, it felt like luck whether I'd get out of it.

What finally fixed that wasn't learning more commands. It was unlearning a handful of things I believed that were simply wrong. Here are the six that mattered most. If you hold any of them too — and most self-taught Git users do — fixing them will do more for you than memorising another twenty flags.

1. I thought a commit was a diff

This is the big one. I thought a commit stored the changes — the lines I added and removed. A little patch, stacked on the patch before it.

It isn't. A commit stores a snapshot of your entire project at that moment. Every file, as it was. Git's own documentation is explicit about this: "Git thinks of its data more like a series of snapshots of a miniature filesystem." (Pro Git, "What is Git?")

Git is smart about storage — files that didn't change between commits aren't duplicated, they're referenced. But the model is snapshots, not diffs. The diffs you see in git show or git log -p are computed on the fly by comparing two snapshots. They aren't what's stored.

Once this clicked, half of Git stopped being mysterious. Why can you check out any old commit and get the whole project back? Because each commit is the whole project. Why is branching cheap? (More on that below.) Because a branch doesn't copy anything — it points at a snapshot that already exists.

If you only fix one belief from this list, fix this one.

2. I thought rebase was dangerous

I avoided git rebase for a long time. I'd read scary warnings: "rebase rewrites history", "never rebase", "you'll lose work". So I stuck to merge and felt vaguely guilty about my messy history.

Here's the truth I wish someone had said plainly: rebase is completely safe on commits you haven't shared yet.

The danger of rebase is exactly one thing — rewriting history that other people have already pulled. If you rebase a branch someone else has based work on, you force them into a painful reconciliation. That's the whole warning. (git-rebase docs — "Recovering from upstream rebase".)

But your own local feature branch, the one nobody else has touched? Rebase it freely. Reorder commits, squash them, clean up messages. You're rewriting history that only exists on your machine. Nobody is affected. And if you mess it up, the reflog has your back (see #6).

"Don't rebase shared branches" is good advice. "Don't rebase" is not — it just keeps you scared of one of Git's most useful tools.

3. I thought `git pull` was always safe

git pull felt like the safe, simple way to get updates. It's not simple, and it's not always safe.

git pull is two commands in a trench coat: git fetch followed by git merge (or git rebase, if you've configured it). (git-pull docs — "git pull runs git fetch ... and then ... git merge".)

That hidden merge is where the surprises live. If your local branch and the remote have both moved on, pull creates a merge commit you didn't ask for. If you have uncommitted changes that conflict, it stops half-finished and leaves you confused. The "simple" command did two things, and the second one had opinions.

What changed for me was separating the steps. git fetch first — that only downloads, it never touches your working files, so it's genuinely always safe. Then I look at what came in (git log HEAD..@{u}), and then I decide: merge or rebase. The decision is mine, made on purpose, instead of baked into a command I ran on autopilot.

4. I thought branches were heavy

I came to Git after a brief, unhappy time with older version-control tools where creating a branch was a big deal — slow, space-hungry, something you did a few times a year.

So I hoarded branches. I'd do too much work on one branch because making a new one felt expensive.

A Git branch is a file containing one line: the 40-character hash of a commit. That's it. Creating a branch writes 41 bytes. It's instant, and it costs nothing. (Pro Git, "Git Branching in a Nutshell" — "a branch in Git is simply a lightweight movable pointer".)

Branches are so cheap that the right habit is the opposite of hoarding: make one for every small thing. Trying an idea? Branch. Reviewing a colleague's work? Branch. Worried a change might not pan out? Branch — if it doesn't work, you just delete the pointer and the snapshots get cleaned up later. There's no cost to being generous with them.

5. I thought HEAD meant "the latest commit"

I assumed HEAD was Git's word for the newest commit — the tip of everything.

HEAD means "where you are right now". Almost always, it's a pointer to the branch you're currently on (which in turn points at a commit). It's not "the latest commit in the repo" — it's "the commit your working directory currently reflects". (Pro Git, "Git Branching".)

This sounds like a small distinction. It isn't. Once I understood HEAD as a cursor — you are here — a whole family of commands stopped being scary. HEAD~1 is "one commit back from where I am". git reset --hard HEAD~3 is "move my current branch back three steps". "Detached HEAD" stopped being an error message I feared and became a plain fact: I'd pointed HEAD directly at a commit instead of at a branch, so I was standing on a commit with no branch name attached.

Git tells you where HEAD is all the time. I just hadn't understood what it was telling me.

6. I thought a commit could be truly lost

The scariest belief, and the one that made me timid. I thought a bad reset, a deleted branch, or a botched rebase could destroy my work for good. So I treated history as fragile and avoided the commands that touch it.

Almost nothing is truly lost. Git keeps a journal called the reflog that records every time HEAD moved — every commit, checkout, reset, and rebase. The commits those entries point to survive in the object database for a while even after nothing else references them: roughly 90 days for commits still reachable, and 30 days for unreachable ones, before garbage collection is even allowed to remove them. (git-reflog docs, gc.reflogExpire config.)

That means a "lost" commit is usually just a git reflog and a git reset --hard <sha> away. I wrote a whole post on exactly how to do that recovery — it's the single highest-ROI thing I learned in Git.

Knowing the reflog exists changed how I work. I stopped being precious about history. I reorder, squash, and reset freely now, because I know the footprints are still there if I need to walk back.

Common myths

Myth: "You have to understand Git's internals to use it well." Mostly false. You don't need to know how packfiles work. You do need the right mental model for a handful of everyday things — commit, branch, HEAD, reflog. That's six ideas, not a computer-science course.

Myth: "Merge is safe, rebase is dangerous." Half true, stated misleadingly. Both are safe on your own unshared work. The only real rule is: don't rewrite history other people have already pulled. That applies to any history-rewriting command, not just rebase.

Myth: "If git status looks scary, I probably broke something." Usually false. Most of the time git status is telling you exactly what state you're in and what to do next — it even suggests commands. The fear comes from not having the model, not from anything being broken. Read it slowly; it's on your side.

The pattern

Looking back, none of my problems were about commands. They were about the model. I'd memorised what to type without understanding what it did, so I couldn't reason about anything new.

That's the whole reason I built GitFlow: a place to practise on a real Git engine, with a live commit graph that shows you the snapshots and pointers moving as you type — so the model builds itself in your head instead of staying abstract.

If you take one thing from this: stop collecting commands. Build the model. Six ideas — snapshots, cheap branches, HEAD-as-cursor, safe-local-rebase, the two-step truth of pull, and the reflog safety net — and Git stops feeling like luck.

What did you get wrong about Git for the longest time? I'm curious which of these six is the most common — or which one I'm still wrong about.

git reflog: the undo button you didn't know you had

Rajat — Tue, 09 Jun 2026 14:20:05 +0000

You've just run git reset --hard HEAD~5. The terminal goes quiet. Your stomach drops.

Five commits — three hours of work — are gone. You didn't push them. You didn't open a PR. Your editor doesn't have them in its undo buffer anymore. The Git object database has freed the references and is going to garbage-collect them eventually.

You can get every one of them back, perfectly, in about forty seconds.

This is the most important command in Git that almost nobody learns until they've already lost work twice. It's called git reflog.

What reflog actually is

A "ref" in Git is just a pointer. HEAD is a ref. Every branch name is a ref. Every tag is a ref. When you make a commit, Git updates whatever ref you're currently sitting on to point at the new commit's SHA. When you switch branches, the HEAD ref moves to the tip of the new branch.

The reflog is a journal of every ref movement. Every time HEAD shifts — every commit, every checkout, every merge, every reset, every rebase step — Git writes a line into the reflog with the previous SHA, the new SHA, and a short reason like "commit" or "reset: moving to HEAD~5".

That journal lives in .git/logs/HEAD and .git/logs/refs/heads/<branch>. It's local to your machine. It's not pushed anywhere. It's not part of the repo. Nobody else can see it.

And, critically — and this is the part that saves your three hours of work — the commits the reflog references are not deleted until garbage collection runs, which by default is 30 days from now. Even when those commits are no longer reachable from any branch, no longer in any working tree, no longer mentioned by any tag — they sit in .git/objects/, untouched, waiting for you to point a branch at them.

A failed reset --hard doesn't delete commits. It just unparks them.

The commands you actually need

There are only three. Memorise them.

git reflog
git reflog show <branch>
git reset --hard <sha-or-ref>

Let's walk through a recovery from start to finish.

Step 1: Look at the reflog

git reflog

You'll get something like:

a1b2c3d HEAD@{0}: reset: moving to HEAD~5
9f4e2c8 HEAD@{1}: commit: feat: wire payment confirmation email
6c1a5e3 HEAD@{2}: commit: feat: add payment confirmation route
3d8f2b1 HEAD@{3}: commit: chore: bump stripe SDK
0e7a9d4 HEAD@{4}: commit: refactor: extract email queue
b4c8e2f HEAD@{5}: commit: feat: add email queue worker
2a1b3c4 HEAD@{6}: checkout: moving from main to feature/payments

Read this top-down as "what HEAD just did, in reverse order". The most recent thing is HEAD@{0} — the reset --hard we just regretted. The five commits we lost are right there at HEAD@{1} through HEAD@{5}.

Step 2: Move HEAD back

The simplest recovery: put your branch back where it was before the reset. The reflog tells you the SHA of the commit you regret leaving — it's the entry that says commit: immediately above the bad reset: line. In the example above, that's 9f4e2c8.

git reset --hard 9f4e2c8

That's it. Your branch is now at 9f4e2c8 again. All five commits are reachable from the tip. git log shows them. Your working tree matches commit 9f4e2c8. Three hours of work, restored.

The four scenarios where reflog saves you

1. Hard reset you regret

The scenario above. Either you reset more than you meant to, or you reset and then realised "wait, I needed that branch state for something."

git reflog                           # find the SHA you want back
git reset --hard <sha>               # move HEAD there

2. Deleted a branch with unmerged work

git branch -D feature/payments
# (panic)

Branches are just refs. Deleting one removes the pointer but leaves the commits intact for the reflog window. Recovery:

git reflog | grep payments           # find the last SHA the branch was at
git checkout -b feature/payments <sha>

3. Rebase ate someone else's commits

You ran git rebase main and resolved a conflict by picking your side. Now you realise that side dropped Alice's commits that were on the branch before you started.

git reflog

Find the entry that says rebase: start or rebase (start). Whatever HEAD was at just before the rebase began is your pre-rebase state. Reset to it.

4. Force-pushed over a teammate's work

Your teammate pushed something. You force-pushed your version over it without pulling first. Their commits are gone from the remote — and from your local, because you git push --force'd.

# On their machine:
git reflog | head -20                # they can still see their commits
git push --force origin feature      # re-publish their state

For this exact reason: never git push --force. Use git push --force-with-lease.

The thing reflog won't save you from

Reflog tracks ref movement. It does not track changes to files you never committed.

If you ran git checkout -- <file> (or its modern equivalent git restore <file>) on a file you'd been editing but never staged, that work is lost. The file's pre-edit state replaced your edits in the working tree, and nothing was ever written to the object database. The reflog can't help.

The rule: anything Git ever assigned a SHA to is recoverable for ~30 days. Anything Git never saw is gone the moment you tell it to discard.

How long do I actually have?

By default, two windows:

Reachable but unreferenced commits (e.g., dangling after a reset): 90 days before git gc is allowed to remove them.
Unreachable commits (orphan branches, dropped stashes): 30 days.

You can also extend these in ~/.gitconfig if you want longer recovery windows:

[gc]
  reflogExpire = 365.days
  reflogExpireUnreachable = 365.days

I run with 365 on personal machines. The disk cost is negligible, and the peace of mind is real.

A practical habit

I keep this command aliased in my .gitconfig:

[alias]
  rl = reflog --date=relative
  oops = !git reset --hard HEAD@{1}

The first gives me a human-friendly reflog with relative dates. The second is the literal undo button: it moves HEAD back to where it was one operation ago, no matter what that operation was. git oops is the muscle memory I want when I realise I just did something wrong.

Try this once today: do a git reset --hard HEAD~1 on a throwaway branch, then recover with git oops. The first time you do it deliberately, the panic-flavored memory of doing it accidentally evaporates.

You don't need to learn Git's internals to ship code. But you do need to know the reflog exists. The next three-hour mistake you save yourself from will make it the highest-ROI five minutes of Git education you ever have.

I wrote this as part of gitflow.dev — interactive Git training with a real Git engine in the browser. Free, no sign-up to read. If you found this useful, the reflog recovery scenario lets you try the recovery in a live terminal.