Git internalsmedium3-5 years
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?
It isn't gone — git reset --hard moves the branch pointer and rewrites the working tree, but it doesn't delete the commit object itself, which still exists in .git/objects under its original hash. git log only shows commits reachable by walking parent pointers backward from wherever the current branch points, and after the reset, the branch no longer points anywhere near the wiped commit, so git log genuinely can't find it by that walk — but "not found by this walk" isn't the same as "destroyed." git reflog is a separate, local record of every place HEAD has pointed, including right before the reset, so it will show the wiped commit's hash directly. git reset --hard <that hash> puts the branch back exactly where it was.
PreviousDuring an interactive rebase, a developer hits a conflict, looks at the `<<<<<<< HEAD` block, and — out of habit from resolving merge conflicts — keeps that side every time. The result quietly discards their own work. What went wrong?Next A service compiles cleanly, but throws `NoSuchMethodError` in production on a code path that calls into a third-party library the team never directly wrote a version for. Where would you look first, and what's the actual mechanism that produces this?
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 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?