Git and GitHub / Editorial solution guide
Recover lost-looking commits and choose revert versus reset
Preserve current work, locate a verified object, and recover through a new reference before deciding how to correct history.
Read-only knowledge base · No public comments
Recognize the symptoms
A commit disappears after switching from detached HEAD, rebasing, resetting a private branch, or deleting a branch name. It may still exist outside the current branch’s reachable history. Another situation is an unwanted published commit that is still visible and needs correction. These are different problems and should not share one automatic hard-reset recipe.
Understand the likely causes
- Reference movement can hide an existing object without immediately deleting it. Local reflogs may record earlier positions, but entries expire and later maintenance can remove unreachable objects. Uncommitted editor changes may never have been recorded by Git. A recovery branch protects a commit, not arbitrary unsaved file content.
Stop unnecessary mutation and preserve current state
Read status and operation state, copy valuable current files through an appropriate separate method, and note current branch tips. Avoid cleanup, pruning, or repeated resets while investigating. Determine whether the missing work was committed, staged, or only in an editor. Do not promise that Git can recover every category. Keep the investigation in a separate temporary lab when practicing, with no changes to actual repository history, configuration, remotes, or credentials. No push is part of this recovery guide.
Inspect local reference history and verify a candidate
Inspect HEAD and relevant branch reflogs, then read a promising commit’s message, tree, and parents. Relative selectors change as new entries appear. The example assumes exactly that a detached lab commit was just created and the next HEAD movement switched to main; under that sequence HEAD@{1} identifies the departed tip. In any other sequence, select from the actual reflog instead. Resolve the verified identity and create a new recovery branch rather than immediately moving main backward.
git reflog -8 --format='%h %gs'
candidate=$(git rev-parse 'HEAD@{1}^{commit}')
git show --stat "$candidate"
git branch recovery/notebook "$candidate"The candidate must be checked against the displayed reflog and content before the branch command. This is contextual lab code, not a universal selector for lost work. main and its newer commits remain unchanged.
Choose recovery and correction by sharing state
Compare the recovered branch with current work and decide whether it needs merging, cherry-picking, or preservation only. If the problem is an unwanted published change, a new correction or reviewed revert usually preserves shared ancestry. Reset can reposition a private branch and, depending on mode, alter index or working files; it is a different operation and can discard data. A merge revert requires a mainline decision and affects later integration behavior. Coordinate shared-history changes rather than force-publishing a local recovery.
Verify the fix
Inspect the recovery branch’s final content and ancestry, run relevant tests, and confirm current work was not overwritten. For a lab bundle backup, restore a separate local clone and verify the expected refs and files. If the object has been pruned or the edit never entered Git, check independent backups and editor recovery and state the remaining uncertainty honestly. A reflog entry or backup filename alone is not proof that the intended content was recovered.
Keep it from recurring
- Create coherent checkpoint commits on named topics, retain verified safety refs during private rewrites, and test backup scope. Reflogs are local and time-limited, not permanent shared archives. Preserve uncommitted files separately before potentially destructive commands. Document the distinction between shared corrective commits and private reference movement in the team workflow.