AlgoMaster Logo

Recovering Lost Work

12 min readUpdated December 6, 2025
Listen to this chapter
Unlock Audio

Losing work is a developer's nightmare, often leading to frustration and panic. Whether it's due to an accidental deletion, an unintentional reset, or a misguided rebase, the experience can feel like a sinking ship. But fear not—Git has built-in features that can help you recover lost work. Understanding how to navigate these scenarios will empower you to manage your repository more confidently.

Understanding the Git Object Model

Before diving into recovery techniques, it’s essential to grasp Git's underlying object model. Git stores everything as objects: commits, trees, and blobs. This structure is foundational to how recovery works.

  • Commits: Each commit represents a snapshot of your project at a specific point in time. Commits are linked in a directed acyclic graph (DAG), where each commit points back to its parent(s).
  • Trees: These represent directories and contain references to blobs (files) and other trees.
  • Blobs: These hold the actual content of files. When you make changes, Git creates new blobs rather than modifying existing ones.

This architecture allows Git to maintain a history of changes, making recovery possible. When you lose work, often, the data is still in the repository; you just need to know where to look.

Recovering Deleted Branches

Accidentally deleting a branch is a common mistake, but it's usually straightforward to recover. Git keeps track of the references to commits, even if you've deleted the branch.

For example, if you deleted a branch called feature-xyz, you can recover it using the reflog. The reflog records all changes made to the tips of branches, even those that are no longer visible in the commit graph.

To find the commit associated with the deleted branch:

This command displays a list of recent actions. Look for the commit hash corresponding to the last state of your branch. Once you have the commit hash, you can recreate your branch:

Undoing a Reset

If you’ve executed a git reset and lost your changes, all hope is not lost. The reflog can also help in this scenario. Let's say you performed a hard reset:

This command resets the current branch to the previous commit, and any uncommitted changes are discarded. However, the commit you just reset is still accessible via the reflog.

To recover from this, use:

Identify the commit hash before the reset. You can then check out that commit directly or create a new branch from it:

Recovering Uncommitted Changes

You may lose uncommitted changes due to accidental deletions or when switching branches. If you find yourself in this situation, there are a few techniques to recover your work.

Stash

If you stashed your changes before switching branches, you can easily recover them. Use:

This command shows a list of stashed changes. To apply the latest stash, run:

If you want to apply a specific stash, reference it with:

Lost Files

If you didn't stash your changes and they were deleted from your working directory, you can check for filesystem recovery tools. However, for files tracked by Git, you can also look into the .git directory:

  1. Check the Object Database: Git stores file contents in the .git/objects directory. If you know the blob or commit hash, you can recover it using:
  1. File Recovery Tools: If the changes were never committed and untracked, you might need to resort to filesystem recovery tools, depending on your operating system.

Dealing with Merge Conflicts

Merge conflicts are another situation where you may feel like you've lost work. A conflict occurs when Git cannot automatically merge changes from different branches. While this situation can be frustrating, it's manageable.

When you encounter a merge conflict, Git marks the conflicted files in your working directory. These markers help you identify what’s conflicting. Here's a typical scenario:

To resolve a conflict:

  1. Open the conflicted file.
  2. Edit the file to reconcile the changes.
  3. Once resolved, stage the file:
  1. Complete the merge:

Using git fsck for Recovery

Using git fsck is another layer of recovery, especially for detecting issues in your Git repository. This command checks the integrity of the objects in the database.

To use it, simply run:

This command will report dangling commits and other issues. If you see dangling commits, you can recover them using their commit hashes.

For example, to recover a dangling commit:

Best Practices for Preventing Data Loss

While recovery techniques are vital, the best strategy is to prevent data loss in the first place. Here are some practices to keep in mind:

  • Regular Commits: Commit work frequently. This creates a safety net that allows you to revert back to previous states.
  • Use Branches: Make liberal use of branches for features, bug fixes, or experiments. This keeps your main branch stable.
  • Frequent Stashing: If you frequently switch contexts, stash your work often. This can save uncommitted changes.
  • Backup: Regularly push your work to a remote repository. This ensures that your changes are safe even if your local copy is lost.

Now that you understand how to recover lost work through various techniques—such as using reflog, handling merge conflicts, and utilizing git fsck—you are equipped to handle situations where things go wrong in your Git repository.

In the next chapter, we will dive deeper into git fsck, exploring how to ensure the integrity of your repository and troubleshoot any issues that may arise. Get ready to strengthen your Git skills even further!