October 12, 2026 · 3 min read · Yunus Emre Vurgun
Recover Git Work Without Losing Local Changes
Before repairing Git history, preserve the state you have. The most damaging recovery command is often the one run before checking which files are uncommitted, untracked, ignored, or owned by another task. Start with status and a clear destination repository.
Make a patch or a task-owned backup for work that must survive. Git can recover a commit it still knows about; it cannot recover an untracked file it never recorded. Ignored configuration and local databases need separate care. A stash with untracked files does not automatically preserve ignored state.
Find the commit and give it a name
git status --short
git reflog show --date=iso
git show --stat <candidate-commit>
git branch recovered-work <candidate-commit>The reflog records local movements of references. It can reveal the commit before a mistaken reset or branch switch. Inspect candidate content, then create a branch pointing to it. That makes the recovery durable without immediately replacing the current working tree.
Reflogs are local and can expire. A teammate’s clone may have a useful reference that yours lacks, but your reflog is not a shared server audit log. Do not run cleanup or aggressive garbage collection while you are trying to recover unreachable history.
Use the repair matching the scope
To undo a change already shared with others, a revert often provides a reviewable new commit without rewriting their history. To restore one file, select the source revision and exact path. To unstage a file, restore the index entry while leaving the working copy in place.
git restore --staged -- path/to/file
git show <commit>:path/to/file
git revert <published-commit>Each operation has a different scope. Inspect the resulting diff and resolve conflicts in terms of the final intended behavior. A cleanly applied revert can still remove code that a later change depends on, so run the checks relevant to the repaired behavior.
Make the final destination explicit
Check remote URLs and the branch before pushing. Prefer a normal fast-forward update when it can deliver the repair. If history rewriting is truly required, coordinate it under the repository’s rules and preserve a rollback reference first.
Finally, compare the recovered files with the original intent, including any local configuration or runtime state outside Git. A successful command is evidence that Git performed an operation; the diff and verification establish whether the work was actually recovered.
Reference tables to keep nearby
- Git Recovery and Inspection Workflows — Recoverable Git workflows for finding commits, restoring selected files, and undoing shared changes.
- Safer Bash File and Process Patterns — Bash patterns for filenames, temporary files, pipelines, and exit status, with portability boundaries.
Primary sources
These are the specifications and project documentation behind the examples. Check the relevant implementation and version before applying a pattern.