Git Recovery and Debugging

Recover lost commits, inspect reflogs, find regressions with bisect, and safely diagnose difficult repository states.

Recovering Work with Reflog

git reflog records movements of references such as HEAD and local branches. It can often help recover commits that are no longer reachable through normal branch references, such as after an accidental reset.

Reflog entries are local and are not part of the shared repository history.

Reflog Is a Safety Net

A commit disappearing from normal branch history does not immediately mean its objects are gone. Reflog can provide a route back while the relevant objects remain available.

Recover an Accidentally Reset Commit

git reflog
# Find the previous HEAD

git branch recovery abc1234
git switch recovery

💡 After locating the desired historical HEAD position in the reflog, creating a new branch at that commit gives the commit a reachable reference again.

Key Takeaways

Reflog records local reference movements.
It is extremely useful after accidental reset or rebase operations.
Reflog is local and should not be treated as a shared backup.

Knowledge Check

What is `git reflog` especially useful for?

Finding Bugs with git bisect

git bisect performs a binary search through commit history to locate the commit that introduced a regression. You mark a known bad commit and a known good commit, and Git repeatedly checks out a midpoint. You test that version and tell Git whether it is good or bad.

Binary Search a Regression

git bisect start
git bisect bad
git bisect good v1.0.0

# test the checked-out commit
git bisect good
# or
git bisect bad

git bisect reset

💡 Git narrows the search range by approximately half after every good/bad classification. Once finished, git bisect reset returns to the original branch.

Key Takeaways

Bisect is efficient for locating regressions in large histories.
Each classification should accurately reflect whether the tested revision is good or bad.
Automated tests can be used with git bisect run.

Knowledge Check

What algorithmic strategy does `git bisect` use?

Cleaning Untracked Files

git clean removes untracked files from the working tree. It can be useful for returning a build directory to a clean state, but it is destructive because untracked files are not recoverable through Git history.

Always use a dry run first with git clean -n.

Untracked Files Are Not Versioned

Git cannot recover an untracked file after git clean removes it. Always preview the operation first.

Preview Before Cleaning

git clean -n
git clean -nd
git clean -fd

💡 -n previews files, -d includes untracked directories, and -f performs the deletion. Never use destructive cleanup blindly.

Key Takeaways

git clean -n is the safest first step.
Untracked files are outside normal commit history.
Use .gitignore to prevent generated files from repeatedly appearing as untracked.

Knowledge Check

What does `git clean -n` do?

Detached HEAD

A detached HEAD occurs when HEAD points directly to a commit rather than to a branch reference. This is normal when inspecting historical commits or checking out tags. You can make temporary commits in this state, but those commits may become difficult to reach after switching away unless you create a branch.

Recover Work from Detached HEAD

git switch --detach abc1234
# make changes and commit

git switch -c experiment
git log --oneline --decorate

💡 Creating a branch while detached gives the new commits a named reference so they remain easy to find.

Key Takeaways

Detached HEAD is not automatically an error.
It is common when inspecting commits and tags.
Create a branch if you want to preserve new commits made there.

Knowledge Check

What does detached HEAD mean?

Recovering Work with Reflog

Finding Bugs with git bisect

Cleaning Untracked Files

Detached HEAD

STAY UPDATED WITH BYTES!