Git detached HEAD: preserve your commits
These blocks describe different cases, not one script. Choose the case that matches your repository. Replace example branch names, file paths and VERIFIED_COMMIT before use. Abort commands apply only to their active operation; do not run both alternatives.
Short answer
Detached HEAD means HEAD names a commit directly instead of following a local branch. You can inspect, build and even commit in this state. If you want to keep new work, create a named branch at the current commit before switching away. A detached checkout is not itself data loss; leaving new commits without a durable reference creates the recovery problem.
The example and its prerequisites
This example starts with a temporary checkout of an older release and two new commits to preserve as a fix branch. This is different from an unfinished rebase or a submodule checkout, which can deliberately use detached HEAD. Read status first. If another operation is active, finish or abort that operation deliberately instead of using a detached-state tutorial to interrupt it.
Inspect before changing anything
git branch --show-current is empty in the ordinary detached case. git status explains the state, and git log shows the current committed history. Record HEAD's object ID before doing anything else. An empty branch name does not mean the repository has no branches, nor that its files are untracked. HEAD and the working-tree contents answer different questions.
git status
git branch --show-current
git log -3 --oneline
git rev-parse HEADKeep a reference or a separate checkout
Create rescue/detached with git switch -c while still at the commit you want. The new branch points to the current commit and keeps its ancestry reachable. This names committed work; it does not turn unstaged file edits into a commit. Inspect and commit those edits separately if appropriate. Use a fresh branch name rather than replacing an existing branch reference with a force option.
git switch -c rescue/detached
git branch --show-currentThe first workflow
After creating the branch, confirm the current branch name, recent commits and patch. You can continue working there or merge/cherry-pick the selected fix into another branch. A cherry-pick copies a change into a new commit; merging joins histories. Choose according to the task and inspect the result. No automatic push is required simply to leave detached HEAD safely.
git log -3 --oneline --decorate
git show --stat HEADChoose the other outcome deliberately
If you already switched away, inspect the local reflog and the candidate commit with git show. Choose the object whose patch and parent are correct, then create rescue/recovered at that verified ID. VERIFIED_COMMIT in the example is a placeholder you must replace. Do not assume HEAD@{1} is always the lost commit: every later checkout or operation can change the relevant entry.
git reflog --date=iso
git show VERIFIED_COMMIT
git branch rescue/recovered VERIFIED_COMMITLimits and exceptions
Reflog records local reference movements. It is not a remote archive, and entries and unreachable objects can expire or be pruned. Uncommitted edits were never recorded as commits by reflog. If your lost work was only in a file buffer or working tree, look for a copy that existed before the loss, such as an editor backup or a verified stash; do not promise a reflog command will recreate it.
Conflicts and cleanup
A submodule often checks out the parent repository's recorded commit in detached HEAD. That is normal when you only consume the pinned dependency. If you intend to develop the child repository, create its own branch inside that repository and follow its contribution workflow. A branch in the parent does not automatically name commits in the child; their references and histories belong to different repositories.
Verify the result
Before deleting a rescue branch, check that a durable branch or reviewed merge still reaches the wanted commits. Inspect status and the patch on the destination. Keep the rescue reference while the work is under review. A branch name is a handle for committed history, not a second physical backup of all project files or an assurance that the fix passes tests.
git log --oneline --decorate rescue/detached
git status --shortCommon questions
Is detached HEAD an error? Not when you intentionally inspect a commit, tag or pinned submodule. Can I commit there? Yes, but name the resulting history before leaving if you want to keep it. Can I recover later? Sometimes, when the local objects and evidence still exist; inspect candidates instead of promising permanent retention.
Review the operation in FluxGit
Use FluxGit’s visual history and patch view to review the operation and the relevant commits. Keep the branch, sharing and local-file checks in this example. The download page lists the currently available builds and platforms.