Source control is designed to preserve history. That makes it excellent for code and dangerous for credentials. Once a password, API key, token, or private key is committed, removing the line in a later commit does not guarantee that the secret is gone.
History preserves old versions
Git stores previous commits so developers can inspect and restore earlier states. A secret removed from the current branch may still exist in an earlier commit and remain easy to retrieve.
Clones and forks create independent copies
Repository history may already exist on developer laptops, build servers, mirrors, backups, and forks. Rewriting the central repository cannot prove that every copy was removed.
Automated systems may capture the value
CI jobs, code scanners, indexing services, dependency tools, and notification systems may process a commit immediately. A secret can therefore spread beyond the Git server quickly.
Rotation is the first response
If a valid credential is committed, invalidate it. Revoke the token, rotate the password, regenerate the API key, or replace the private key according to the affected system. Treat cleanup of repository history as a secondary containment step, not a substitute for rotation.
Use secret-scanning tools
Pre-commit checks, repository scanners, and provider-side secret detection can catch common credential formats. Scanning cannot identify every proprietary secret, but it shortens detection time.
Use configuration references instead
Applications should retrieve secrets from environment variables, protected CI/CD variables, container or orchestration secrets, or a dedicated secret manager. Commit example configuration with placeholder values, not operational credentials.
Review developer workflows
Teams should know how to create local configuration safely, how to request development credentials, and how to report accidental exposure. The secure path needs to be easier than pasting a production key into a config file.