The commit unlocked more than you expected. Hidden in the diff were columns no one should see. Now you need to pull them out before they leak.
git checkout is the fastest way to revert files or parts of files, but sensitive columns require a more deliberate approach. The goal is precision: keep safe data intact, strip only the high‑risk parts.
Start by identifying the exact range. Use git diff to see the changes and pinpoint the lines containing sensitive columns. If it’s just specific fields in a table definition, avoid resetting the entire file. Staging can be selective.
Run:
git checkout <commit> -- path/to/file
This restores the file from a previous commit, before the sensitive columns were added. For partial changes, pair git checkout -p with interactive mode. You can choose which hunks to keep and which hunks to discard, line by line.
If the sensitive columns have already been committed, reclaim control by creating a new commit without them. Remove those fields in code, verify the schema, and commit the fixed version. Then push to override the exposed changes.
Audit history. Use git log -p to trace when the columns entered the project. If you must rewrite history to eliminate them from all commits, use git filter-repo or git rebase -i. These commands let you surgically remove sensitive data from past commits while keeping other changes untouched.
The key to handling sensitive columns is speed, accuracy, and no guesswork. Every second they remain in the repo increases risk. Git gives you the tools to fix it at commit level or even deeper in history.
Want to skip manual repair and hard‑won command knowledge? See how hoop.dev detects and blocks sensitive columns before they land in your branch. Spin it up in minutes and see it live.