Troubleshooting Git Problems — git-basics

No matter how careful you are, disaster strikes. You reset too hard. You rebased the wrong branch. You deleted something precious. Panic sets in—until you remember Git’s secret weapon: the reflog. Git is surprisingly forgiving, and most disasters are recoverable if you know where to look. This chapter is about troubleshooting, recovering, and learning to treat Git less like a bomb and more like a safety net.

The Nature of Git Disasters

Typical catastrophes include:

Accidentally deleting branches.
Resetting with --hard and losing commits.
Rebasing and overwriting history.
Force-pushing bad history.
Losing track of HEAD.

Most feel final, but Git usually has a memory of your actions.

Visualization of disaster:

flowchart TD
  CommitA[Commit A] --> CommitB[Commit B]
  CommitB --> CommitC[Commit C]

  Reset[git reset --hard A] --> Detached[HEAD -> A]
  Detached --> Dangling["Commits B + C become dangling (invisible)"]

Lost doesn’t mean gone—it means dangling, recoverable.

The Reflog: Git’s Black Box Recorder

Reflog records every move HEAD makes: checkouts, commits, merges, resets. It’s your flight recorder.

git reflog

Example output:

a1b2c3d HEAD@{0}: commit: fix bug
e4f5g6h HEAD@{1}: rebase finished: returning to refs/heads/main
7h8i9j0 HEAD@{2}: reset: moving to HEAD~2

Each entry is a breadcrumb back through time.

Recovering with Reflog

Suppose you reset too far:

git reset --hard HEAD~3

Commits seem gone. But reflog shows their hashes. Restore:

git checkout a1b2c3d
git branch recovery a1b2c3d

Your lost work is back.

Undoing a Merge

If a merge goes wrong:

git merge feature
# disaster
git reset --hard ORIG_HEAD

ORIG_HEAD points to the commit before the merge.

Undoing a Rebase

Rebasing can feel dangerous. To abort mid-rebase:

git rebase --abort

If already finished badly, reflog can roll you back:

git reset --hard HEAD@{3}

Common Disaster Scenarios

Deleted Branch

git branch -d feature
git reflog
git checkout -b feature a1b2c3d

Recovered from reflog.

Force Push Overwrite

If you force-pushed wrong history, reflog on your local machine still knows the old commits. Fetching from teammates can also help recover.

Detached HEAD Mistakes

You commit in detached HEAD, then switch branches. Commits seem gone. But reflog shows them:

git checkout -b rescue HEAD@{1}

Visualization of Recovery

flowchart TD
  Start[HEAD reset too far] --> Reflog[git reflog shows commit hash]
  Reflog --> Restore[git checkout lost commit]
  Restore --> Branch[git branch recovery]

Git lets you time travel back to safety.

Solo Workflow Example

As a solo dev, you panic after losing commits with a reset. Reflog saves you:

git reflog
git checkout a1b2c3d

Now you look like a magician.

Team Workflow Example

On a team, disasters happen when force-pushes overwrite history. Good communication and reflog recovery bring things back. Pair programming during disaster recovery turns a scary moment into shared learning.

Visualization of team recovery:

flowchart LR
  Dev[Dev force-pushes bad history] --> Panic[Team panics]
  Panic --> Reflog[Use reflog locally]
  Reflog --> Restore[Branch restored]
  Restore --> Push[Push fixed history]

Preventing Disasters

Avoid --hard unless sure.
Don’t force-push to shared branches.
Use protected branches on remotes.
Commit often—small commits reduce risk.

Think Different Mindset

Git disasters aren’t failures—they’re lessons. Git teaches resilience: mistakes are recoverable, history is flexible, memory is long. Reflog is your parachute. Once you know it, fear fades. You experiment more, knowing safety nets exist.

Git can feel like a landmine field, but with reflog and recovery tricks, it’s actually forgiving. Most “lost” work isn’t lost, just misplaced. Master these tools, and you’ll never fear Git again. In the next chapter, we’ll explore Copilot instructions—how to craft guidance for AI assistants to make your Git life smoother.