Git and GitHub / Advanced: trust, scale, and recovery / Lesson 18

Reflogs, reachability, and recovery planning

Recover verified committed work without turning an investigation into an unnecessary destructive rewrite.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain local reflogs and object-retention limits.
Anchor recovered commits and verify before integration.

Identify what is actually missing

A commit can disappear from the current branch view while its object still exists. A deleted branch, detached experiment, rebase, or reset can change reachability without immediately erasing content. Uncommitted edits are a different category and may never have entered Git’s object database. Start with status, current refs, operation state, and a copy of valuable current files. Avoid cleanup, pruning, or repeated reset commands during diagnosis. The first task is to identify the missing object or file state, not to force the branch to look familiar at the cost of newer work.

Read local reference movements

Reflogs record updates to local references under their configuration. HEAD’s reflog often includes checkouts and commits, while a branch reflog records that branch’s movements. They are local recovery evidence, not a shared audit log automatically fetched from GitHub. Entries can expire and unreachable objects can later be removed by maintenance. Do not promise a universal retention window or permanent recovery. Relative selectors such as HEAD@{1} change meaning as new operations add entries, so inspect them and resolve a verified object identity before acting. A command copied from another person’s reflog is not your own recovery target.

Create a recovery reference before rewriting anything

The lab assumes a detached commit was just created and then the user switched back to main, with no later HEAD-changing commands. Under that exact sequence, HEAD@{1} names the departed detached tip. Inspect it before creating a new branch, and keep the candidate variable tied to the verified object. In a real recovery, identify the appropriate entry from the actual reflog rather than blindly using this selector. Creating a branch at the object preserves reachability while leaving the current branch untouched. This makes comparison and deliberate integration safer than immediately resetting the current line.

bash Anchor a verified detached lab commit

git reflog -6 --format='%h %gs'
candidate=$(git rev-parse 'HEAD@{1}^{commit}')
git show --stat "$candidate"
git branch recovery/notebook "$candidate"
git log -1 --format=%s recovery/notebook

The selector is valid only for the stated lab sequence and must be checked against the displayed reflog and content. recovery/notebook is a new local lab branch; main is not moved. The final subject matches the recovered experiment’s message.

Preserve committed references with a lab bundle

A Git bundle can package reachable objects and references for offline transfer or backup under its selected scope. It does not automatically include untracked files, uncommitted edits, every configuration file, or all reflog-only objects. Anchor important recovered commits first. The example writes a bundle only to the disposable lab parent and verifies its repository prerequisites. A production backup plan should test restoration and include the other data it promises to protect. A file called backup is not evidence of recoverability until a restore has been exercised under a known scope.

bash Create and verify an offline bundle inside temporary storage

git bundle create ../notebook-lab.bundle --all
git bundle verify ../notebook-lab.bundle

Both repository and parent path must be allocated lab storage. --all selects refs known to this repository; it does not save the working tree. Validation additionally restores a separate local lab clone from the bundle, with no network or push.

Integrate recovered work according to sharing state

After anchoring, compare the recovered commit with current work and decide whether to merge, cherry-pick, or simply preserve it. For an unwanted published change, a new corrective commit or reviewed revert usually preserves shared ancestry; reset addresses a different reference and file-state problem. Avoid force publication during recovery unless separately coordinated and authorized by the project, and no such action occurs here. If the object is already pruned or the edit was never recorded, look to independent backups and editor recovery rather than promising Git can reconstruct every lost byte. Document the verified recovery and improve checkpoint and backup habits.

Common errors and fixes

A copied reflog selector points to the wrong commit

Why it happens: Relative entries changed after more operations.
How to fix it: Inspect current reflog and verify the resolved object.
Prevent it next time: Anchor verified candidates promptly.

A bundle is assumed to include unsaved edits

Why it happens: Reference backup is confused with working-file backup.
How to fix it: Preserve uncommitted files through an appropriate separate method.
Prevent it next time: State and test backup scope explicitly.

Repeated cleanup destroys remaining recovery evidence

Why it happens: Maintenance commands run before diagnosis and anchoring.
How to fix it: Stop unnecessary mutation and inspect surviving refs and objects.
Prevent it next time: Use a preserve-inspect-anchor-verify recovery sequence.

Check your understanding

1. A commit is absent from log main but appears in HEAD reflog. What is a cautious first preservation step?

Show worked solution

Inspect its content and parents, resolve its object identity, and create a new recovery branch at it. This preserves reachability without moving main or discarding newer work. Integration can be reviewed afterward.

2. A lost editor change was never staged or committed. Can reflog guarantee recovery?