Oops, I Committed a Secret: A Calm Guide to Scrubbing Git History

Karam Khoury — Fri, 24 Jul 2026 12:00:25 +0000

You just finished a great feature. You're in the flow.

git add .
git commit -m "Fixed the bug!"
git push

Then you see it, staring back from the GitHub UI: your live API key. 💀

We've all been there. Here's the calm, correct order of operations — from "quick save" for a mistake you caught instantly, to the deep clean for a secret that's been buried in history for months.

Step 0: Rotate the secret first (yes, before anything else)

This is the step people skip, and it's the only one that's non-negotiable. The moment a secret hits a remote, assume it's compromised. Bots scrape public GitHub for credentials within seconds.

So before you touch history:

Revoke / rotate the leaked key, token, or password at its source (AWS, Stripe, your DB, wherever).
Then clean the repo.

Cleaning history without rotating is like changing the locks after posting the old key online. Rotate first, always.

Case 1: You caught it before pushing (the quick save)

If the secret is only in your last, un-pushed commit, this is trivial:

# Stop tracking the file and ignore it going forward
git rm --cached .env
echo ".env" >> .gitignore

# Fold the fix into the last commit
git commit --amend --no-edit

Done. Nothing left the building. (Still rotate the key if it was ever real.)

Case 2: It's deep in history, or already pushed (the deep clean)

Once the secret is several commits back — or on the remote — you need to rewrite history. The modern, recommended tool is git filter-repo (Git's own docs now steer you here instead of the old filter-branch).

# Install (Python)
pip install git-filter-repo

# Option A: remove a whole file from ALL history
git filter-repo --path config/secrets.yml --invert-paths

# Option B: redact a specific string everywhere it appears
echo 'AKIAIOSFODNN7EXAMPLE==>REDACTED' > replacements.txt
git filter-repo --replace-text replacements.txt

Prefer BFG Repo-Cleaner if you like a faster, simpler tool for the common cases:

bfg --delete-files id_rsa
bfg --replace-text passwords.txt

# Expire the old refs and garbage-collect
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Then: force-push and warn your team

History rewriting changes commit hashes, so you must overwrite the remote:

git push --force

⚠️ This rewrites shared history. Tell every collaborator to re-clone or hard-reset — if someone merges an old local branch, the secret comes right back. And remember: on GitHub, the old commit can still be reachable via its hash / cached views for a while, which is exactly why Step 0 (rotation) is what actually protects you.

Prevention: never live on the edge again

.gitignore first. Add .env, *.pem, secrets.* before the first commit.
Environment variables / a secret manager (Azure Key Vault, AWS Secrets Manager, Doppler) — secrets never touch the repo.
A pre-commit scanner so a secret is blocked before it's committed:

# gitleaks catches secrets in staged changes
brew install gitleaks
gitleaks protect --staged

Wire that into a pre-commit hook and the "cold sweat" moment mostly disappears.

TL;DR

Rotate the secret (non-negotiable, do it first).
Un-pushed? git commit --amend.
In history? git filter-repo or BFG, then git push --force.
Tell your team to re-clone.
Add a pre-commit scanner so it never happens again.

How do you handle secrets in your workflow — pre-commit hooks, or living life on the edge? 👇

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

System Design: The 6 Core Load Balancing Algorithms, Explained

Karam Khoury — Fri, 24 Jul 2026 11:58:19 +0000

Stop guessing how your traffic scales — understand the routing mechanics. Here's how the six core algorithms actually dictate traffic distribution, and when to reach for each.

1. Round Robin

Distributes requests sequentially across the server pool.

Example: Dealing a deck of cards — Server A gets request 1, Server B gets 2, Server C gets 3, then the cycle repeats. Best for identical, stateless servers.

2. Weighted Round Robin

Sequential routing that accounts for unequal hardware.

Example: Server A has 64 GB RAM, Server B has 32 GB. Assign weight 2 to A and 1 to B, and A receives exactly twice as many requests.

3. Least Connections

Routes traffic to the server with the fewest active, open sessions.

Example: Joining the supermarket checkout with the fewest people. Ideal for long-lived connections — WebSockets, heavy database queries.

4. IP Hash

Uses a hash of the client's IP to guarantee the same client hits the same server every time.

Example: A user at 192.168.1.50 is always routed to Server C. Mandatory for legacy stateful apps that store session data in-memory rather than a distributed cache.

5. Least Response Time

A hybrid: lowest number of active connections combined with the lowest average response time.

Example: Joining the line that has both the fewest people and the fastest cashier. Essential when server performance degrades unpredictably.

6. Adaptive (Resource-Based)

Routes based on real-time hardware telemetry from an agent on each server.

Example: The load balancer queries CPU, memory, and I/O wait in real time, and avoids any server spiking above 80% utilization.

Takeaway

Choose your algorithm based on your infrastructure and state management — not trends. Build systems that scale predictably.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure), building secure, scalable fintech systems. More at karamkhoury.me.

DEV Community: Karam Khoury