A librarian checks out an old catalog-sync tag to compare behavior and then makes a new commit that never appears on any branch tip. What Git state explains this?
Select an answer to reveal the explanation.
Short Explanation
Detached HEAD is like writing in a notebook that is not filed under any binder—easy to lose the pages. Checking out a bare tag puts you there. New commits will not move main or your feature branch until you attach them.
Full Explanation
Checking out an old catalog-sync tag places Git in a detached HEAD state: HEAD points at a commit (the tag’s target) rather than at a named branch reference. Commits created in that state advance HEAD but do not move main, develop, or any feature branch tip. Unless those commits are pointed to by a new branch or tag before the checkout moves elsewhere, they become easy to lose and will not appear in normal branch listings or pulls.
A protected-main rule that rewrites every commit onto origin/main automatically is not how branch protection works; protection blocks unauthorized updates—it does not silently relocate detached commits. A successful fast-forward merge of main into a feature branch updates a branch tip by definition, the opposite of “never appears on any branch tip.” A pre-commit hook that silently relocates commits to a release branch would be an unusual and dangerous custom setup, not the standard explanation for tag checkout behavior.
Exam caveat: detached HEAD is normal for inspections and builds from tags; the hazard is making new commits without creating a branch. git switch -c rescue-branch (or equivalent) captures work. Garbage collection can eventually prune unreachable commits, so “I’ll find it in reflog later” is a weak municipal recovery plan.
Operational check: run git status after checking out the tag and confirm detached HEAD messaging; if experimental commits were made, create a named branch immediately, push it, and open a PR rather than switching back to main and wondering where the commit went.