What's the best way to prevent accidental github leaks? I once accidentally leaked an API key (albeit for a relatively unimportant service, and I realized soon afterwards).

Don't write keys into code, even "test" code. Discipline yourself (and your team) to use dedicated key storage even on test systems, (and of course that key storage isn't "Duh, a github repo" but an appropriate technology for your platform)

If you instinctively want to write

shiny_api_key = 'SOME.KEY.BOSS.EMAILED.ME'

Force yourself to instead take the extra few minutes to do

# my-cloud-vendor key-store create shiny_api_key SOME.KEY.BOSS.EMAILED.ME

and then write

shiny_api_key = key_store_access('shiny_api_key')

This way, when six hours later you check that code in, to GitHub, and go home for the weekend, you won't get a call from the boss ruining your Sunday lie-in, "WTF Did you upload our $5000 shiny API key to GitHub? You are fired".

This habit also allows for correct separation as an organisation grows, when you're big enough you want it to be possible for somebody to write code against test systems with test API keys, and that same code to work as written in production, even though production API keys are not accessible to the coders. Using key stores to mediate makes this much more likely to actually work.

yowlingcat

This is the wrong answer. At a company I worked at, we had a well known saying: "Favor mechanisms over good intentions." As the saying went, if good intentions worked, we "wouldn't need mechanisms."

The right answer here (as stated in sibling comments) is to install a mechanism into the build. A push that accidentally commits credentials should break the build. How it goes about doing that is up to you, but the specific way I've done that in the past is a git hook [1] specifically the pre-commit hook. It looks like there's a reasonably well-updated package by Yelp to help do this kind of thing [2].

[1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks [2] https://github.com/Yelp/detect-secrets