Code10x
Git internalseasy0-2 years

A developer runs `git checkout <some old commit hash>`, makes a few commits while poking around, then switches back to `main` without naming anything. Are those commits gone? What actually happened?

The commits aren't deleted, but they are effectively lost unless recovered quickly: checking out a commit hash directly (instead of a branch name) puts HEAD into "detached" state, meaning .git/HEAD holds a raw commit hash instead of a reference to a branch file. Any commits made in that state are real, valid objects, written exactly like any other commit — but no branch file points at them. The moment the developer switches to main, nothing in the repository's normal ref set names those commits anymore, so they become unreachable: still physically present in .git/objects, but with no name to find them by, and git log won't show them. They aren't destroyed, but without recovering the hash — from the terminal scrollback or git reflog — they'll eventually be garbage-collected.

The lesson behind it →
PreviousA teammate avoids creating branches for small changes because "branching is expensive — it copies the whole project." Is that true in Git, and what does `git branch feature` actually do?Next A merge fails with `CONFLICT (content): Merge conflict in config.txt`, and the file has three lines. A developer assumes the whole file is now in question and starts rewriting it from scratch. What does Git actually mean by a conflict here, and what's the right way to read the markers?
More on Git internals
A teammate avoids creating branches for small changes because "branching is expensive — it copies the whole project." Is that true in Git, and what does `git branch feature` actually do?A developer runs `git reset --hard HEAD~1` on the wrong branch, wiping out a commit they needed. `git log` no longer shows it. Is the commit actually gone, and how would you get it back?