CI/CD
Why can't you just remove a secret from Git after committing it?
Short answer
Because git is built to remember. A commit is content-addressed and immutable, so deleting the file adds a new commit that removes it — while the original stays reachable, in your history and in every clone anybody already made.
The constraint behind it
Git stores content as objects addressed by their own hash, and commits point at them. That immutability is the entire basis of the guarantees people rely on: that a hash identifies exactly one tree, that history can be verified, that two clones with the same hash are the same code.
Deleting a file therefore cannot mean "unwrite the past". It means adding a commit whose tree omits the file. The blob containing your secret is still there, still reachable from the earlier commit, and still exactly one `git show` away.
Rewriting history can remove it locally, but every clone is a complete copy. Anyone who pulled before the rewrite keeps the original, and rewriting shared history has its own consequences.
◈ If it were the other way
What that system would look like
For a version control system to genuinely forget, history would have to be mutable — a commit's content could change after the fact.
Which would remove the thing that makes git trustworthy. A commit hash would stop identifying specific content, so you could no longer verify that what you have is what was reviewed, signed or built. Reproducible builds depend on the opposite of forgetting.
This is a real trade and git chose deliberately: perfect memory, and a burden on the person committing. Every system that can forget gives up verifiability to do it.
◆ What it buys you
- Verifiability. A hash pins exact content, which is what makes signed commits, reproducible builds and artifact provenance possible at all.
- Distribution without trust. Every clone is complete, so no central server has to be believed.
- History as evidence. You can prove what a file contained at any point, which is the whole point of an audit trail.
◑ What it costs you
- Every mistake is permanent by default. Not just secrets — large binaries, personal data, anything committed once.
- Revocation becomes the only real remedy. Rotating the credential is the fix; removing the file is housekeeping.
- The window is unknowable. You cannot tell who cloned the repository before you noticed, so "we caught it quickly" is not a measurement you can actually make.
Where it bites in practice
In how reassuring the cleanup feels. A `git rm`, a commit, and a green build all confirm that the file is gone — and every one of those signals is about the working tree, not about history. The credential is still valid, still recoverable, and the team has stopped worrying about it.
What comes next
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere