LEARN. PRACTICE. GROW.Separate content, reference, and local editing
An engineer creates a fix in a detached checkout and then switches to main. The fix may remain as an object even without its own branch. A different situation is a file never stored in Git disappearing from the filesystem. These are not the same problem. For the first, investigate references and local reflog; for the second, seek editor copies, backups, or other appropriate mechanisms. Before any recovery, preserve current editing and identify what was actually lost: a reference, commit, index selection, or never-recorded file.
Rescue an observed commit
In the lab, switch --detach allows an experimental commit without advancing main. After returning to main, the runner finds the ID in HEAD reflog and creates a rescue branch at that ID. Show rescue:app.txt confirms its content. Creating the reference does not require resetting the current worktree. In a real investigation, inspect the candidate before integrating it: similar messages do not guarantee the same fix. The experiment does not recover never-saved files and does not test retention after cleanup. Reflog is local and can expire; it should not be the only backup plan.
Choose a merge parent
Reverting a merge requires a comparison mainline. Inspect the object and its parents, for example with log --format=%P -1 M, and relate them to the integration performed. Do not choose -m 1 solely by habit or infer parent order from message dates. In the lab, main merges feature with --no-ff; the first parent represents the mainline intended to remain. Revert --no-edit -m 1 M creates a compensating change and feature content disappears. This local exercise explains the choice; it does not validate application-data rollback.
Explain why the same merge does not restore the feature
After reversal, the lab runs merge feature again without new source commits. HEAD does not change and the feature remains absent from the file. The earlier merge remains in ancestry: content was compensated, but integration history was not erased. This is useful during an incident meeting when someone proposes repeating the merge to restore behavior. The team needs a corrected reintroduction plan, which may involve reverting the revert or new commits depending on history. Reintroducing content without fixing the original defect repeats the functional risk.
Communicate recovery and its limits
Deliver an explanation identifying the found object, created reference, confirmed content, and tests still needed. For a reverted merge, include the parent graph and reintroduction strategy. The runner records six observation groups and its own artifact hash in evidence.json. Commands ran in disposable repositories without remotes or real-project data. Summary: a commit without a branch can be rescued while it exists; reflog is not unlimited backup; revert does not erase ancestry. Connect this lesson with recovery, release traceability, and functional validation.
The detached commit was rescued; the same merge after revert did not reintroduce the feature.
Common pitfalls
Reflog as a copy of all files; reset before preserving work; revert as deleting history.
Related topics: Working tree, index, and commit · Branches, merge, and rebase · Reverse changes and preserve work
Preserve references and interpret ancestry before promising functional recovery.
Reference: Git: reflog · Git 2.56; workflow concepts compatible with modern Git 2.x