error: failed to push some refs" secret detected by push protection
Recovers from git's 'failed to push some refs' when the cause is secret detection by push protection: find the offending commit, remove the secret, and push again. Use when a push is rejected for a detected secret. Not for non-fast-forward or permission rejections.
TL;DR
The push was rejected because push protection found a secret in one of the commits being pushed. Identify the flagged commit, remove the secret from it (rewrite the commit if needed), and push again. The secret never reached the remote, so containment is about your local history.
Error
"error: failed to push some refs" secret detected by push protectionSteps
- Read the full push output; push protection names the secret type and usually the file. Expected: you know which commit and file triggered the block.
- Check whether the commit is already on the remote:
git log origin/[branch]..HEAD --oneline. Expected: if the commit is only local, you can rewrite it freely. - If the secret is in the tip commit, remove it and amend: edit the file,
git add,git commit --amend. Expected: the amended commit no longer contains the secret. - If it is deeper in history, do an interactive rebase or history rewrite to drop the secret from that commit. Expected: every local commit is clean.
- Push again. Expected: the push succeeds with no protection block.
When to use
git pushfails and the output mentions secret detection or push protection.- The rejected commits exist only on your machine.
When not to use
- The rejection is non-fast-forward (fetch and rebase instead).
- The secret already reached the remote (rotate it; rewriting is not enough).
Tool compatibility
- Git with GitHub push protection; any secret type it detects.
Variant phrasings
remote rejected push: secret detected
Same block, different wording.
push protection blocked the push
Identical handling.
Why it happens
Push protection scans the pushed commits before accepting them. It rejects the whole push if any commit contains a known secret pattern.
Edge cases
- If teammates already pulled the bad commit, they need to drop it too after you rewrite.
- Bypassing push protection is possible with org permission but leaves the secret in history; prefer removal.
- Large binary files with embedded secrets need the same rewrite treatment.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstRx5PohPiq_qgKT5VFrZQA