AI-assisted: these definitions come from the Git glossary we keep at LearnSome.tech, turned into a post with help from an AI tool and checked against the Git documentation. I run LearnSome.tech; you don't need it to use any of this.
If you committed it, it's very likely still there, even after a bad reset or rebase; you just need the words to find it. (Changes you never committed or stashed are another story, which is why the last section matters.) Here are four words worth knowing.
1. The reflog
What it is: Git's local record of every position HEAD and each branch has pointed at.
Every commit, checkout, reset, rebase and merge adds an entry such as HEAD@{2}. So after a bad reset --hard or a rebase that went wrong, the old commit is usually one command away:
git reflog # find the line from before the mistake
git branch rescued <commit-id> # put a branch on it so it can't get lost
Know its limits: it lives only in your clone (a teammate's reflog won't help you), and entries expire, by default after about 90 days, or 30 for commits nothing points at any more.
2. Detached HEAD
What it is: HEAD holding a commit ID directly instead of a branch name.
You get there by checking out a commit, a tag or a remote-tracking branch. It's a normal state for looking around, not an error. The catch: if you make commits while detached, no branch moves to follow them, and Git warns you when you leave because they'll only survive while something points at them.
git switch -c keep-this-work # before or after leaving: give the commits a branch
3. git stash
What it is: a command that saves your uncommitted changes aside and returns the working tree to the last commit.
git stash # staged and unstaged changes to tracked files
git stash list # what's saved
git stash pop # reapply the newest entry and drop it from the list
The gotcha: untracked files stay where they are unless you add -u. People stash, switch branch, and then wonder why a new file followed them.
4. The staging area (the index)
What it is: Git's list of exactly what the next commit will contain, kept in .git/index.
It holds a complete tree, not just a list of changed names. git add copies a file into it as it is at that moment, so if you edit the file again after adding it, the staged copy stays as it was. That's why git status can show the same file as both "staged" and "modified".
git diff # working tree vs the index: what you haven't staged
git diff --staged # the index vs the last commit: what will be committed
The habit that ties them together
Before any command that rewrites history (reset, rebase, commit --amend), run git status and glance at git log --oneline -5. If something goes wrong, you'll recognise the commit you need in the reflog.
Which of these four have you had to look up in a panic?
Top comments (0)