A secret was committed to git: revoke it first, then decide whether to rewrite history

Treat the credential as exposed

A credential that has been committed should be treated as compromised, whether or not anyone is known to have used it. GitHub's guidance is that the first step is to revoke or rotate the secret, and that once it is dead a history rewrite may not be worth the effort. Rotation belongs to whoever holds the account behind the credential: the person who can revoke the key at the provider and issue a replacement. Do that before anything else, and keep the provider's access and billing logs, because they are the only way to learn whether anyone used it. If you see unexpected use, you have an incident, and your own incident process and the provider's guidance come first.

• Revoke or rotate first, then look at the repository.
• Do not paste the secret into a ticket, a chat or an enquiry while you work on it.

Stop tracking the file, and know that ignoring it is not enough

Adding a file to the ignore list does not remove it from a repository that already tracks it. The Git documentation says files already tracked are not affected by ignore patterns. To stop tracking a file, remove it from the index with git rm --cached, which leaves the copy on disk, and add its name to the ignore file so later commits do not bring it back. This change only affects future commits. Every earlier commit still contains the file, so the value is still in the history, in every clone and in every fork until the history itself is dealt with.

• Replace a literal value in code with a setting read from the environment or a secret store, and add an example file with placeholders.
• Check that the application still starts with placeholders in a test environment.

What a history rewrite does and does not do

A rewrite removes the value from history on your copy. GitHub notes that git-filter-repo version 2.47 or later has a flag for sensitive data removal, and that publishing the result needs a force push which cannot be undone. Commit hashes change and signatures are dropped, open pull requests can lose comments, and anyone who pulls and pushes from an old clone can bring the value back. Clones, forks, pull requests and cached views may still hold the data, and GitHub states that you cannot remove it from other people's clones. GitHub Support can clear cached views and pull-request references in some cases, and fork owners must clean up their own forks. Keep a full backup of the original before publishing.

• Tell collaborators in advance and ask them to re-clone after the rewrite.
• Because of the limits above, rotation is the control that protects the account. The rewrite is housekeeping.

Stop the next one, and how the paid job is accepted

Secret scanning push protection blocks a push that contains a detected potential secret, and allows a bypass with a reason that creates an alert and an audit event. Repository-level protection is off by default and needs the right plan and an administrator to enable it. Detection is of a potential secret, so a false positive is possible, and the page does not list which kinds of secret are covered, so check the supported patterns for the services you use and treat the feature as one layer. The committed-secret job works after you rotate: it finds each occurrence in files and history with redacted values, changes the code to read configuration, prepares the rewritten copy and the publishing steps, adds a scan configuration and writes a rotation checklist that you complete and mark yourself. We never receive your replacement key, and we do not investigate misuse. Do not send the secret or the repository in the first enquiry.