Introduction

A common Git cleanup scenario is deleting files from disk first and then needing Git to record those deletions in the next commit. Git still tracks those paths until you stage the deletions. The fix is simple, but doing it safely at scale requires careful status checks and selective staging.

Core Sections

Inspect deleted tracked files

Start by checking repository status so you can see which tracked files are missing from disk.

git status

Deleted tracked files appear under unstaged changes. Review this list before staging if the cleanup was broad.

Stage all tracked deletions safely

To stage every tracked file deletion detected in working tree, use one of these commands:

git add -u
# or
# git commit -a -m "..."  # if you want direct commit with tracked modifications

git add -u stages deletions and modifications of tracked files but does not include new untracked files.

Stage only missing tracked files by explicit list

If you want tighter control, list deleted tracked files and pass them to git rm.

git ls-files --deleted
git rm $(git ls-files --deleted)

This approach can be useful when cleanup is mixed with other pending edits and you want clear staging intent.

Commit and verify the result

After staging deletions, commit with a message that explains why files were removed.

git commit -m "Remove obsolete generated files"
git status

Always re-check status to ensure only intended paths were committed.

Use pathspecs when deleting by area

For monorepos or large projects, scope staging to one directory or extension so unrelated changes are not included.

git add -u docs/
git add -u "*.md"

Pathscoped staging prevents accidental commits during large repository maintenance.

Update .gitignore to prevent reintroduction

If deleted files are generated artifacts, add ignore rules so they do not return in future commits.

# build artifacts
/build/
*.log

Ignoring these paths after cleanup reduces repeat churn in pull requests.

Handle already-committed large artifacts separately

If deleted files were large binaries committed in history, removing them from current commit does not shrink repository history. History rewrite is a separate operation and should be planned carefully.

For normal source cleanup, staging and committing deletions is enough. For security or storage incidents, coordinate a dedicated history rewrite process.

Add cleanup checks to CI or pre-commit hooks

Teams with frequent generated-file churn can add checks that fail when tracked deleted paths are left unstaged or when ignored artifacts are reintroduced.

Automated checks keep repository hygiene consistent and reduce manual review noise.

Split cleanup commits from feature work

When deleting many obsolete files, create a dedicated cleanup commit instead of mixing it with feature code. Review becomes easier, and rollback is safer because file-removal intent is isolated from behavioral changes. This also helps blame and history analysis later.

If cleanup spans several directories, split by subsystem and commit incrementally. Smaller commits make code review faster and reduce merge conflict risk on active branches.

This practice also helps automated release notes, because each commit describes one cleanup intent instead of many unrelated deletions.

Common Pitfalls

• Deleting files from disk and forgetting to stage deletions in Git.
• Running broad staging commands without reviewing git status first.
• Mixing unrelated modifications into cleanup commits.
• Removing generated files without adding .gitignore safeguards.
• Assuming current deletion commit removes data from full repository history.

Summary

• Git tracks deleted files until deletions are explicitly staged.
• Use git add -u for safe bulk staging of tracked deletions.
• Use pathscoped staging for cleaner, lower-risk commits.
• Add ignore rules to prevent deleted artifacts from returning.
• Treat history rewrite as a separate process when old large or sensitive blobs remain.