DEV Community 👩‍💻👨‍💻

Discussion on: Removing Sensitive Data From Git History

Collapse
 
patricknelson profile image
Patrick Nelson • Edited on

I think this needs a few big disclaimers:

Secrets: This doesn't really purge secrets (if it's ever been pushed); once they're out, they're out for good. It may look "squeaky clean" now, but once you've pushed to git, consider it compromised forever, particularly since anyone could have pulled it in between your first push and when you fixed the problem. Always reset/rotate secrets once you've made this mistake! Github's own help section elaborates on this further: help.github.com/en/enterprise/2.17...

History rewrites: When working with other people, history rewrites on a branch that others may be using is generally considered a big "no no". This is because once it's been pushed, it could get pulled by someone else and once that happens, their next pull will end up forcing a merge-commit because the other users commit history will still be untouched. This creates a mess, so this requires that all other users who may have pulled to then also perform a local reset/rebase against the latest from the remote that they pulled from (can be difficult once they've made changes since then).

See: mirrors.edge.kernel.org/pub/softwa...

For true distributed development that supports proper merging, published branches should never be rewritten.

TL;DR: Don't push credentials, if you do, consider them compromised and reset everything. Avoid rewriting pushed/public branches (especially master), if you have to, notify everyone who may have pulled the rewritten branch so they can reset/rebase their changes (or simply don't rewrite).