We have all been there. You are excited about a project, your code finally works, and you rush to push it to GitHub. You type git add ., git commit, and git push.
Then, reality hits you. You just published your database credentials and secret API keys to a public repository.
When I was an amateur developer, I did exactly this. I accidentally pushed both my .env file and a local SQLite database file to GitHub. It felt like the end of the world, but it was one of the best learning experiences of my career.
Here is exactly what went wrong, how I fixed it, and how you can prevent it from ever happening to you.
π¨ The Disaster: What Actually Happened
Like many beginners, I treated Git like a simple backup tool rather than a version control system. I had a standard Node.js project structure:
my-awesome-app/
βββ node_modules/
βββ src/
βββ .env <-- Contains database passwords & API keys!
βββ database.db <-- Contains actual application data!
βββ package.json
βββ server.js
I blindly ran git add .. Because I had not configured my project to ignore confidential files, Git happily tracked .env and database.db and pushed them straight to a public GitHub repository.
Why this is dangerous:
- GitHub Scrapers: Bots constantly scan public commits for terms like DB_PASSWORD or AWS_SECRET. Your credentials can be stolen within seconds.
- Data Leakage: Pushing a database file exposes your users' private data or your hard-earned test data to the entire world.
π οΈ The Immediate Fix: How to Clean It Up
Simply deleting the file and making a new commit does not work. Git remembers everything. The sensitive files will still exist in your commit history, and anyone can look back and find them.
If you just did this, follow these steps immediately to wipe the files from your history and secure your project.
Step 1: Add the files to .gitignore
Create a file named .gitignore in your root folder (if you do not have one yet) and add these lines:
.env
*.db
Step 2: Purge the files from Git tracking
Tell Git to stop tracking these files without deleting them from your local computer:
git rm --cached .env
git rm --cached database.db
Step 3: Completely wipe them from your history
To completely erase the files from past commits, use the filter-repo tool or this built-in Git command:
git filter-branch --force --index-filter \"git rm --cached --ignore-unmatch .env database.db" \
--prune-empty --tag-name-filter cat -- --all
Step 4: Force push the clean history
Update GitHub with your scrubbed history. Warning: This overwrites the remote repository.
git push origin --force --all
Step 5: Rotate your secrets! (Crucial)
Assume your keys are already compromised. Go to your database provider or API dashboard and regenerate every single password and token that was in that .env file.
π‘οΈ Prevention: How to Protect Your Code Moving Forward
Mistakes happen, but automation ensures they only happen once. Here is how to bulletproof your future repositories.
1. Use an .env.example file
Never leave future developers (or yourself) guessing what variables the project needs. Create an .env.example file that contains the keys but leaves the values blank. Commit this file safely to GitHub.
.env.example
PORT=3000
DATABASE_URL=your_database_url_here
API_SECRET_KEY=your_secret_key_here
2. Install a Global Gitignore
Prevent yourself from making this mistake across all future projects. Set up a global ignore file on your computer for databases and system files.
git config --global core.excludesfile ~/.gitignore_global
echo "*.db" >> ~/.gitignore_global
3. Use git-secrets or Pre-Commit Hooks
You can install tools like git-secrets or use a pre-commit hook package like husky. These tools automatically scan your code for secrets before allowing a commit to go through, blocking the action if a password or .env pattern is detected.
π‘ Conclusion: Normalize Mistakes, Maximize Security
Making mistakes is a fundamental part of the developer journey. Pushing a secret to GitHub feels terrible in the moment, but it forces you to learn about Git history management, environment isolation, and security best practices.
Have you ever accidentally leaked a credential? What tools do you use to prevent it? Let me know in the comments below!
Top comments (1)
i've had that exact moment of oh no right after the push felt so good. the excited then rush then regret order is painfully familiar.