Case Study: Recovering a 'Lost' Commit Chain from Detached HEAD

This is a real recovery walkthrough — the actual conversation, questions, and commands used to find and reattach a commit chain that had fallen off every branch in a local repo (v5-pakcli / v5-main / v5). Kept here as a reference for next time.

1. The Problem (in the user’s words)

“I accidentally save my project, with no branch. And I accidentally switch to other branch, .. I think I lost those”

Then, once git reflog was run:

“Okay. They have a lot of head of any… there’s a lot of… yeah. There’s a fluid message.”

And the core ask, once the reflog was pasted in:

“i dont undestand a single thing lol why it keep my file i wasnt a corrrect a branch ?? how it still storage itt
how to fix it ? and save to the x branch actualy
and what is todo for so this cant happen later on”

Later, after reviewing the reflog more closely:

“you see there is non branch commit i wannt recover that
like these line of commit that not mention any branch… can i fix it recover it?”

And finally, narrowing the target:

“I WANT ALL COMMIT IN THAT LATEST COMMIT THAT LOST the latest is fix: frontend
help me recover from it”

2. What Was Actually Going On

The repo had three branches in play: v5, v5-main, and v5-pakcli. Somewhere in the history, work was done while not on any branch — a state called detached HEAD — and a chain of 4 commits was made there:

graph LR
    462a083["462a083<br/>fix(explorer): CHANGED GITIGNORE..."] --> fe90667["fe90667<br/>feat(ui): refine sidebar..."]
    fe90667 --> a2ad774["a2ad774<br/>feat(ui): replace book icon..."]
    a2ad774 --> ac8d6bc["ac8d6bc<br/>fix: frontend"]
    style ac8d6bc fill:#f96,stroke:#333,stroke-width:2px

Right after committing ac8d6bc, the reflog showed a checkout straight over to v5-main — meaning this whole chain was left behind, attached to nothing. It still existed in git’s object database (nothing is deleted immediately), but with no branch label pointing at it, so it wouldn’t show up in git log on any branch, and would eventually be garbage-collected if left alone long enough.

How we confirmed it was actually orphaned

Not everything without a branch name next to it in the reflog is lost — most reflog lines are just intermediate steps on the way to a commit that is labeled. The real test:

git branch --all --contains ac8d6bc

Empty output = no branch contains that commit = genuinely unattached. That’s what happened here:

$ git branch --all --contains ac8d6bc
$

Nothing came back. Confirmed orphaned.

3. The Recovery Plan

flowchart TD
    A["Orphaned commit: ac8d6bc<br/>(fix: frontend)"] --> B["git checkout -b recovered-frontend-fix ac8d6bc"]
    B --> C["New branch anchors<br/>the whole 4-commit chain"]
    C --> D["git checkout v5-pakcli"]
    D --> E["git merge recovered-frontend-fix"]
    E --> F{"Fast-forward<br/>possible?"}
    F -- Yes --> G["Pointer moves forward,<br/>no merge commit needed"]
    F -- No --> H["Merge commit created,<br/>resolve conflicts if any"]
    G --> I["git push origin v5-pakcli"]
    H --> I
    I --> J["git branch -d recovered-frontend-fix"]

Step-by-step commands used

1. Anchor the orphaned commit to a real branch, so it can’t be garbage collected:

git checkout -b recovered-frontend-fix ac8d6bc

2. Switch to the target branch and merge it in:

git checkout v5-pakcli
git merge recovered-frontend-fix

3. A GUI dialog appeared asking about “fast-forward”:

“Are you sure you want to merge ‘a2ad774413eb0900e6567d2c4e0253105074c3d2’ into your current branch?”
☐ Create a new commit even if fast-forward is possible

4. Clean up once confirmed merged:

git push origin v5-pakcli
git branch -d recovered-frontend-fix

4. Fast-Forward vs. Merge Commit — What’s the Difference?

This was the last point of confusion, worth keeping as a reference.

graph TB
    subgraph "Fast-forward merge"
    A1[Commit 1] --> B1[Commit 2]
    B1 --> C1[Commit 3 - recovered work]
    ptr1((branch pointer)) -.moves straight to.-> C1
    end

graph TB
    subgraph "Merge commit forced"
    A2[Commit 1] --> B2[Commit 2]
    B2 --> C2[Commit 3 - recovered work]
    B2 --> D2[New merge commit]
    C2 --> D2
    ptr2((branch pointer)) -.moves to.-> D2
    end

	Fast-forward (checkbox unchecked)	Forced merge commit (checkbox checked)
What happens	Branch pointer just slides forward	A new commit is created tying both histories together
When it’s possible	Only when the current branch hasn’t diverged from what you’re merging in	Always possible
History looks like	A single straight line	A visible “merge point” in the graph
Best for	Recovering/reattaching commits, simple linear work	Team workflows where you want a record of when a feature branch was merged (e.g. via pull requests)

Decision made: leave the box unchecked. Since v5-pakcli hadn’t diverged in a conflicting way from the recovered chain, a fast-forward was the cleanest option — no unnecessary merge commit clutter for what was essentially just reattaching lost work.

5. Outcome

All 4 commits — 462a083, fe90667, a2ad774, and ac8d6bc (fix: frontend) — are now part of v5-pakcli’s history, pushed to origin/v5-pakcli, with no data loss and no duplicate commits.

“oke it work thanks”

6. Key Lessons for Next Time

Git rarely deletes anything immediately. A commit not on any branch is “orphaned,” not gone — it just needs a branch pointer to make it findable and safe again.
git reflog is the first move whenever something seems lost. It logs every HEAD movement locally.
git branch --all --contains <hash> is the real test for “is this commit actually attached to anything?” — don’t assume from reflog formatting alone.
To recover: anchor the orphaned commit with git checkout -b <new-branch> <hash>, then merge or cherry-pick it into where it belongs.
Fast-forward is fine and preferred for simple recovery merges — it keeps history clean. Save forced merge commits for cases where you actually want a visible merge marker (e.g., team pull requests).
To prevent this going forward: run git status and check the current branch before starting work, and avoid checking out a raw commit hash directly (git checkout <hash>) unless intentionally exploring — that’s what causes detached HEAD in the first place. Use git switch -c <name> <hash> instead if you want to explore and keep the work safe.

Quartz 5

Explorer