GitHub push protection blocked your push — what are your options and what does each cost?

## Reading the block A push protection rejection is a server-side refusal, so it arrives as `remote:` output from the push. It tells you four things: that a repository rule violation stopped the push, the human name of the secret type detected, the commit and path/line where the match sits, and a URL to unblock. That level of detail is deliberate — the fastest fix requires knowing *which* commit is dirty. ## Option one: remove the secret The critical mechanic is that push protection evaluates **all commits in the push**, not the resulting tree. A developer who notices the block, deletes the line, and commits the deletion will be blocked again, because the earlier commit that introduced the key is still part of what is being pushed. The remedy is to rewrite the offending commits so the credential is not in any of them, then push again. That is ordinary Git work — amend or interactive rebase — and it is easy while the commits are still local and unshared, which is precisely why push protection is worth so much more than post-hoc scanning. While you are there, replace the credential with something the codebase can carry safely: reading from the environment, or a placeholder that is obviously not a key. ## Option two: bypass The unblock flow requires a reason, and the options map to real situations: - **It's used in tests** — the value is a fixture, not a live credential. - **It's a false positive** — the string matches a pattern but is not a credential at all. - **I'll fix it later** — you accept it is real and are choosing to unblock now. Whichever you pick, the push succeeds and GitHub records the bypass; a secret scanning alert is raised for the value, so it appears in triage rather than vanishing. The reason matters operationally because bypass reasons are reviewable: a repository whose bypasses are overwhelmingly "used in tests" has a fixture problem, while one full of "fix it later" has a process problem. ## Delegated bypass Organisations that do not want bypass to be self-service enable **delegated bypass for push protection**. The developer's unblock attempt becomes a **request**, routed to a designated bypass list — typically a security team or repository admins — who approve or deny it. This converts an individual decision made under deadline pressure into a reviewed one. The tradeoff is latency: someone has to be available, or pushes stall. Most organisations run it on their highest-risk repositories rather than everywhere. ## What the bypass actually costs If the value was genuinely a fixture or a false positive, the cost is one alert to close with the matching resolution. If it was real, the cost is a leak: it is now in the repository's history, in every clone and fork made afterwards, and potentially in CI logs and mirrors. Rewriting history later does not undo any of that. The only response that changes the credential's risk is revoking and reissuing it — the block you bypassed was the last cheap moment. This is the point interviewers listen for. A candidate who says "I'd click bypass and clean it up later" has misunderstood the control. The correct answer under deadline pressure is: bypass only if the value is not a live credential; if it is live, rotate it first — a key you have already revoked is no longer a secret, and then the block is trivially resolved. ## Things that do not work - Force-pushing around the check: push protection is evaluated on the push itself, not on branch state. - Adding the file to `.gitignore`: it only affects untracked files going forward and does nothing about commits already in the push. - Excluding the path from alerting: path exclusions shape which matches raise alerts; they are not a way to make push protection ignore a live credential. ## Guidance for teams Make the fast path obvious. Most blocks are honest mistakes by people who now have a broken push and a deadline, and the quality of your outcome depends on whether the easy option is "rewrite the commit and move on" or "click bypass". Document the rewrite recipe somewhere findable, keep obviously-fake fixture values in tests so the fixture case stops arising, and review bypass reasons periodically so you find the systemic causes instead of the individual ones.