How to Prevent Committing Secrets to Git for Good (Simply Explained)
A plain-language guide to prevent committing secrets. No jargon, no tech speak, just what it means for your business.
By Mike Hodgen
The Mistake You Can't Undo
Let me explain a problem that has cost real companies real money.
When developers build software, they often need passwords and access keys. Think of these like the master key to your office building. It opens everything: your files, your customer data, your bank-connected systems.
Sometimes a developer accidentally saves that master key into the shared project files. And here's the part nobody understands until it burns them: once that key gets saved and shared, you can't take it back.
It's not like deleting an email. The key gets copied to every laptop on the team. It lands in backup systems. It sits in logs. Someone could have grabbed it an hour before you noticed. You don't get to know.
I've found real keys like this sitting in code I work with. Not test keys. Actual admin access. Keys with full read-and-write power over a company's database. Sitting there for months.
Cleaning Up Is the Wrong Battle
Most teams fight this the wrong way. They find a leaked key, panic, and try to scrub it out of the project history.
Here's why that's mostly theater. You can erase the key from your records, sure. But you can't erase it from the dozen laptops that already have a copy. You can't recall it from the backups or the person who downloaded the project this morning.
So the moment a key leaks, you have to assume it's compromised. Which means you have to "rotate" it: shut off the old key and create a new one. That sounds simple. In practice it means downtime, scrambling to update every system that depended on the old key, and a real chance you miss one and break something at the worst moment.
Now compare the two costs. Cleaning up a leaked key takes hours, and the damage is already done. Stopping the key from leaking in the first place takes a fraction of a second.
That gap is the whole point.
The Wall That Stops It Before It Happens
The fix I install is a simple gatekeeper. Think of it like a metal detector at the airport, except it sits in front of the developer's project.
Every time someone tries to save their work, this gatekeeper scans what they're about to save. It's looking for things that look like keys and passwords (those random-looking strings of letters and numbers). If it spots one, it stops the save dead. The key never gets in. Nothing to clean up, nothing to rotate, nothing to explain to your board.
I use a tool called gitleaks for this. The beauty is the speed. It only checks the new stuff you're saving, not your entire project, so it runs in a fraction of a second. Developers don't even notice it's there until the day it saves them.
That speed matters more than it sounds. A security tool that's slow and annoying gets switched off. And a switched-off security tool is worse than none, because everyone thinks they're protected when they're not.
This matters more now because of how fast code gets written. AI tools can build a feature in 20 minutes, but they're also notorious for pasting keys right into the files where they don't belong. Fast building means fast leaking.
Install Once, Protect Everything
Here's where this goes from a nice habit to real coverage.
You can install this gatekeeper one time on a computer, and it automatically covers every project on that machine. New project, old project, one you downloaded five minutes ago. All protected by default.
For a CEO, that's the line that matters. This isn't a chore your team has to remember to set up every time. It's on by default. And "on by default" is the only kind of security that survives a busy team.
But I never trust a security tool I haven't tried to break. So after installing it, I test three things. I try to save a real key on purpose (it should block me). I save normal clean work (it should let me through). And I test a brand-new empty project, because that's where these things sometimes glitch.
A gatekeeper that quietly fails and lets everything through is more dangerous than no gatekeeper at all. So you prove it stops the bad stuff and prove it allows the good stuff. Both halves.
The Trap Nobody Warns You About
There's one catch worth knowing, and it's sneaky.
Some modern projects set up their own security gate that overrides your machine-wide one. When that happens, your gatekeeper is no longer in the line. It's just not there.
Here's the cruel irony. The projects most likely to do this override are exactly the modern, fast-moving ones most likely to leak keys in the first place. So your team feels protected everywhere, but has a blind spot in the riskiest projects.
When I work across a lot of code, I check for this on purpose. I once audited 58 separate projects in a single day, and finding which ones quietly bypassed the global protection was one of the first things I looked for. You don't get credit for the projects you covered. You get a breach from the one you didn't.
Sweep the House Before You Trust the Lock
One more thing. The gatekeeper stops the next leak. It does nothing about keys already sitting in your history right now.
So before you relax, you run a one-time sweep across your whole project history to find what's already leaked. When I did this across the code I work with, I found six real credential leaks sitting there. The discipline is separating the real ones from the false alarms, then shutting off and replacing every real one.
The order isn't optional: sweep first, replace every key you find, then trust the gatekeeper going forward. Install the lock but skip the sweep, and you've locked the front door while the back door hangs wide open with the keys still in it.
What This Does, and What It Doesn't
Let me be honest about the limits, because anything oversold becomes something you resent later.
This gatekeeper is one layer, not the whole wall. It won't stop a developer who deliberately works around it. It doesn't cover everything that happens after the code leaves their hands.
What it does is make the most common and most expensive mistake nearly impossible to make by accident. Because most leaks aren't malicious. They're a tired engineer pasting a key into a file at 6pm on a Friday. This catches that.
The whole setup costs a fraction of a second per save and a one-time install. For a CEO who lies awake worrying about one leaked key turning into a data breach and a public disclosure, this is the cheapest insurance you'll ever buy.
I install controls like this across every project I touch, and the approach scales from one to dozens.
Ready to bring AI leadership into your company?
I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.
Get AI insights for business leaders
Practical AI strategy from someone who built the systems — not just studied them. No spam, no fluff.
Ready to automate your growth?
Book a free 30-minute strategy call with Hodgen.AI.
Book a Strategy Call