What's the trade-off between rewriting Git history to remove a committed secret versus simply rotating it and leaving the now-worthless value in history?

Leaving it in history (after rotating) is simpler, has zero risk of breaking other people's clones or in-flight work, and is safe precisely because the value is now worthless — the only real cost is that the string remains visible to anyone browsing history, which can look bad and occasionally trips automated scanners repeatedly. Rewriting history actually removes the string, but requires force-pushing (rewriting every affected commit's hash), which breaks every existing clone/fork's history alignment, requires coordinating everyone to re-clone or carefully re-base, and only makes sense as a genuinely worthwhile trade for a highly public/scrutinized repository where the residual visibility itself is unacceptable.

Rotate and leave in history: once a credential is rotated, the old value in Git history is inert — it can't be used to access anything anymore, so its continued presence in history is purely a cosmetic/hygiene concern, not an active security risk. This is the simpler, lower-risk path: no force-push, no coordination burden, no risk of breaking anyone's existing clone or in-progress work. The cost is that the (now-worthless) string remains visible to anyone with repo access browsing history, which can look unprofessional, might repeatedly trigger automated secret-scanning tools flagging the same already-remediated finding, and — in the exceptionally unlikely case scanning tools can't perfectly distinguish "still valid" from "already rotated" — occasionally generates noise or false alarm follow-ups.

Rewrite history to remove it: tools like git filter-repo (the modern recommended tool, superseding the older git filter-branch and BFG Repo-Cleaner in most guidance) can actually remove the secret from every commit that contained it, producing a genuinely clean history. But this fundamentally changes every commit from that point forward (since a commit's hash depends on its content and its parent's hash — rewriting one commit changes every commit built on top of it), meaning it's a real, disruptive history rewrite: everyone with an existing clone or fork now has a history that's diverged from the rewritten one, requiring them to discard their local history and re-clone (or carefully reconcile any in-progress work), and it must be force-pushed to the remote, which — per the earlier force-push discussion — carries its own risk of clobbering anyone else's concurrent work if not carefully coordinated.

The practical decision: for most private, internal repositories, rotate-and-leave is the pragmatic default — the disruption cost of a history rewrite (coordinating every collaborator's re-clone, the force-push risk) usually outweighs the purely cosmetic benefit of removing an inert string from history. History rewriting becomes genuinely worth the disruption specifically for highly public or heavily scrutinized repositories (a widely-used open-source project, a repository under active security audit) where the residual visibility itself — even of a rotated, worthless value — is a real reputational or compliance concern worth the coordination cost to actually remove.

• A rotated secret's old value in Git history is inert — its continued presence is a hygiene/visibility concern, not an active security risk.
• Rewriting history to remove it requires a disruptive force-push, breaking every existing clone/fork's alignment and requiring coordinated re-cloning.
• Rotate-and-leave is the pragmatic default for most private/internal repositories, given the low actual risk versus the real disruption cost of a rewrite.
• History rewriting is worth the disruption specifically for highly public or heavily scrutinized repositories where residual visibility itself is a real concern.

• GitHub Docs: Removing sensitive data from a repository
• git-filter-repo documentation