VibeSecurity

Fix

Fix: GH013 Push cannot contain secrets (GitHub push protection)

GitHub's push protection scans commits as you push and rejects the push if it finds a known secret format. It has saved you from publishing a key. The job now is to take the key out of your commits, not to get around the block.

By the VibeSecurity team3 min read

What this means

The push fails with 'remote: error: GH013: Repository rule violations found' and a line reading 'Push cannot contain secrets', followed by the secret type, the commit id and the file path and line. Nothing reached GitHub. GitHub's docs are clear on the resolution: you must remove the secret from all of the commits it appears in. Deleting it in a new commit is not enough, because the earlier commit still carries it.

Why it happens

  • A key was pasted directly into source code while prototyping, often by an AI tool filling in a working example.
  • A .env file was committed because .gitignore was missing, or was added after the file was already tracked.
  • A config, notebook, test fixture or log file containing a token was added with git add .
  • You removed the secret in a later commit, but the original commit is still in the branch you are pushing.

How to fix it

  1. 1Read the error. Note the commit id and file path for each detected secret.
  2. 2Rotate first if the key has left your machine in any way: a previous push to any remote, a shared zip, a chat, a paste into an AI tool. If you are unsure, rotate. It takes minutes.
  3. 3Move the value into an environment variable and add the file to .gitignore.
  4. 4If the secret is in your latest commit only: remove it from the file, then run git commit --amend --all and push.
  5. 5If it is in an older commit: run git log to find the earliest commit that contains it, start git rebase -i <COMMIT-ID>~1, change pick to edit for that commit, remove the secret, run git add . then git commit --amend, then git rebase --continue, and push.
  6. 6If a .env file was tracked, untrack it with git rm --cached .env as part of the amended commit.
  7. 7If the secret did reach GitHub earlier, for example before push protection was on, follow GitHub's guide to purge it from history with git filter-repo after rotating.
Git: remove the secret from the latest commit, or an older one
git rm --cached .env
echo '.env' >> .gitignore
git add .gitignore
git commit --amend --all
git push

git log --oneline
git rebase -i COMMIT_ID~1
git add .
git commit --amend
git rebase --continue
git push

How to confirm the fix

Before pushing, search every commit on your branch for the start of the key. The command should print nothing. Then push: a clean push is the final confirmation. Afterwards, check the Security tab of your own repository for open secret scanning alerts.

Git: search your own branch history for the key
git log -p --all -S 'FIRST_12_CHARS_OF_THE_KEY' --oneline

git ls-files | grep -E '^\.env'

Frequently asked questions

I deleted the key and committed again. Why is the push still blocked?

The earlier commit still contains it, and a push sends every commit. Rewrite that commit with amend or an interactive rebase so the key never appears in the history you push.

The push was blocked, so the key never reached GitHub. Must I still rotate it?

If it truly never left your machine, the risk is low. Rotate anyway if it was ever pushed elsewhere, shared, or pasted into an online tool, or if you cannot be certain.

Is it safe to rebase?

On commits you have not pushed, yes. If others have already pulled the branch, rewriting it needs coordination, as GitHub's guide on removing sensitive data explains.

How do I stop this happening again?

Keep secrets in environment variables, keep .env in .gitignore from the first commit, review git status before committing, and leave push protection switched on.

Sources

  1. 1.GitHub: Working with push protection from the command line
  2. 2.GitHub: About push protection
  3. 3.GitHub: Push protection for users
  4. 4.GitHub: Removing sensitive data from a repository
  5. 5.GitHub: Ignoring files