A commit vanished. The logs tell part of the story, but not all. Something happened in the repository, and you need answers fast. This is where forensic investigations meet the precision of git reset.
Git offers a range of commands for moving the HEAD and rewriting history, but when things break—or are broken—every detail matters. Forensic Git work is about more than restoring a commit. It is about reconstructing the sequence of events, understanding intent, and preserving evidence.
When and Why to Investigate
A git reset can be harmless. It can also erase commits, change the index, and rewrite timelines in ways that hide mistakes or conceal changes. Investigating means isolating the moment of reset, identifying affected commits, and determining whether it was soft, mixed, or hard. Each type impacts the working directory and staging differently, leaving unique patterns in the reflog, file history, and diff output.
Tooling for Git Forensics
Start with git reflog. It lists every change to HEAD, including those caused by git reset. Use timestamps to build a clear timeline. Compare with git log --stat to match commits against file-level changes. For deeper inspection, git fsck uncovers dangling commits and objects—often critical for recovery work.