How to Recover Deleted Code with Git Log: A Step‑by‑Step Guide

1. Problem Background

The code of page A mysteriously disappeared, and it was unclear when it was removed.

After discovering the issue, the team wondered why the code deletion escaped the code‑review (CR) process despite having a CR workflow.

We want to retrieve the missing code, identify the commit that caused the deletion, and understand the operation to prevent similar incidents.

2. Solution

2.1 Find commits that modified a specific file using git log

The file has been deleted, but based on the project structure we infer that A/index.js originally existed.

To inspect the history of that file, run:

git log --stat --full-history --simplify-merges -- A/index.js

The output shows that the commit labeled fix: 1 removed 200 lines of code, and no later commit touched the file, indicating the file was deleted in that commit.

By checking out the commit just before the deletion (e.g., git checkout 6df716248794c3c54873f73002b8bd0854ac0805), you can retrieve the file's contents prior to removal.

2.2 Explain each command and its parameters

2.2.1 git log to view commits affecting a file

git log -- A/index.js

Using this simple form may return nothing if the file no longer exists in the current tree.

Therefore we first restore the file and then run the command again.

The restored view shows only the commit that added the file back; earlier deletions are hidden because of git log's default simplification strategy.

Git log, by default, collapses history when multiple branches lead to the same final state, so commits that cancel each other out (e.g., a file created then deleted) are omitted.

2.2.2 --stat to generate diff statistics

Without any options, git log does not show file diffs:

Adding --stat produces a summary of changed files and line counts:

git log --stat -- A/index.js

2.2.3 --full-history to disable history simplification

Adding --full-history disables the default simplification, showing every commit that touched the file:

git log --full-history -- A/index.js

2.2.4 --simplify-merges to filter out merge commits

While --full-history reveals all commits, it also includes merge commits that may be irrelevant. Adding --simplify-merges removes those empty merges:

git log --full-history --simplify-merges -- A/index.js

The resulting list contains only commits that actually modified the file.

Combining --stat, --full-history, and --simplify-merges yields the final command used throughout the article:

git log --stat --full-history --simplify-merges -- <path>

3. Analysis of the Cause

3.1 Why the deletion was missed during code review

The deletion occurred in the commit fix: 1 . The internal code‑review platform (similar to GitLab) did not display any record of the deletion.

Running git show on that commit also shows no file changes, explaining why the issue was invisible during the review.

3.2 Why the platform and git show cannot display the commit

3.2.1 Platform conclusion

To verify, we reproduced the scenario in a test repository with two branches. Branch A added new2.js and modified const.js. Branch B later also modified const.js, causing a merge conflict.

When new2.js was removed from the staging area and the conflict was resolved by choosing “Current Change”, the deletion was not shown in the platform’s history.

However, VSCode’s Git view still displayed the file removal:

3.2.2 Further analysis

After merging, the main branch path turned red, indicating that the changes from branch A were overwritten by branch B’s merge. Consequently, the fix: fix1 node shows no file changes on the platform, and the newly added new2.js appears as if it never existed.

Returning to the original project, opening the commit in VSCode’s Git panel reveals many file modifications, including the deletion of page A’s code, matching the behavior described above.

4. Preventive Measures

Currently, code deletions are discovered only after they cause problems, which is why the issue went unnoticed for eight months.

We aim to shift from a passive to an active approach by building a "main‑branch inspection" tool that periodically scans the repository for similar anomalies and notifies developers promptly.