Undo Accidental Push to Public Git Repo

So, if you’re reading this, it’s likely because you’ve pushed something sensitive to a Git repo. We’ve all been there.

But there’s no time for dillydallying. Let’s fix this immediately!

To undo the previous commit, run the following:

git reset --hard HEAD~1

If you wanted to undo the past two commits, you could run the following, and so on:

git reset --hard HEAD~2

Once you’ve undone however many commits you need to undo, forcefully replace your head with the most recent non-undone commit:

git push -f origin <branch>

Be sure to replace <branch> with the name of the branch to be overwritten.

Okay, you’re safe now. Let’s talk about it.

1. You should never do this unless you absolutely have to.

2. You should never, ever, ever do this unless you absolutely have to.

3. But there are times when this is necessary, so that you can mitigate the data leakage.

4. You should email, or otherwise notify, all of the repository’s collaborators that they will need to set up their branch all over again, because their histories will no longer match the new branch.

Once you’ve pushed something sensitive to a public repository, you should always assume it’s been compromised - even if you managed to successfully rewrite the head just a few minutes later.

On GitHub, for example, bots have already been made to detect and grab private keys within minutes, waiting for an accidental push.

Preventing future accidental pushes

The single most common cause for accidental commits that I have seen is when a sensitive file was included in .gitignore, but still somehow got staged.

This can usually be prevented by adding ignore rules to your .gitignore before you add any untracked files or folders to the workspace.

For example, let’s say you add a .env file that contains some private keys to your workspace, and then you add an ignore rule for .env to your .gitignore.

You then run a git add ., commit, and push. But to your shock, the .env file (with your private keys) is still included in the commit!

This is because you forgot to add the ignore rule before adding the file. So please, always remember to do this - especially if you default to staging files with the git add . command.

There are many other causes, of course. Some other things that come to mind are:

• Automated commits including sensitive data.

• Mistakenly uploading the wrong file or folder to a workspace.

• Forgetting sensitive data was still in a file from testing. An example would be if you used a private API key in a file for testing but forgot to remove it before committing.

Anyway, always think twice before running that git push command.

It never hurts - and check the spelling on our commit messages while you’re at it! I’ve saved myself from countless silly typos this way.

Conclusion

There’s a lot of blog posts and a lot of snippets on this topic.

But many involve instructions for reverting just local commits or use unnecessarily fancy techniques.

I tried to balance non-invasiveness with reliability for the commands I’ve included in this post, although there is really no “non-invasive” approach to dealing with this kind of situation.

Good luck! I hope a robot (or human) didn’t steal your data.