IntermediateIn-depth4 min readUpdated 2 Oct 2026

What is .gitignore, and what would you do if you accidentally committed a password or API key?

SHORT ANSWER

.gitignore lists files Git should not track, like .env, node_modules and build output. If a secret was committed, first revoke or rotate it, because anyone who saw it can use it. Then stop tracking the file, add it to .gitignore, and if it was pushed, remove it from history with git filter-repo or BFG and force push.

Explain it simply

A .gitignore file is a list of things Git should pretend are not there. Typical entries are passwords and keys in .env, installed packages like node_modules/, build output like dist/, log files, and editor settings.

The tricky part: .gitignore only affects files Git is not already tracking. If you already committed .env, adding it to .gitignore later does nothing to the copy in history.

And if that commit was pushed to GitHub, the secret is public the moment it lands, especially in a public repository. Automated bots scan GitHub for leaked keys within minutes. So deleting the file is not enough. The key itself must be treated as stolen.

Example

A simple .gitignore for a Node.js project:

text

# dependencies
node_modules/

# environment and secrets
.env
.env.*
!.env.example

# build output and logs
dist/
*.log

The ! line means "do track .env.example", a template file with dummy values that tells teammates which variables they need.

Now suppose you committed .env with a real payment gateway key and pushed it.

Step 1. Rotate the secret immediately. Log in to the provider's dashboard, revoke the leaked key and create a new one. Update it in your local .env and your server settings. Check the provider's logs for any misuse.

Step 2. Stop tracking the file:

bash

echo ".env" >> .gitignore
git rm --cached .env
git commit -m "Stop tracking .env"

--cached removes it from Git but keeps it on your disk.

Step 3. Remove it from history (all old commits still contain it):

bash

git filter-repo --path .env --invert-paths
git push --force --all

git filter-repo is a separate tool you install. It rewrites every commit without that file. The BFG Repo-Cleaner is an alternative.

Step 4. Tell the team. Everyone must re-clone or reset their copies, because the history has changed.

How it works

Git matches each path against the patterns in .gitignore files (the root one, ones in sub-folders, and your global ignore file). A trailing / matches only folders, * matches anything except /, ** matches across folders, and ! re-includes something an earlier pattern excluded. Tracked files are never ignored, which is why git rm --cached is needed.

Real-world use

Every project starts with a .gitignore; GitHub offers templates per language when you create a repository.
Teams store secrets in environment variables, a cloud secret manager, or the CI system's secret settings, never in the code.
GitHub secret scanning and push protection can block a push that contains a known type of key. Tools like gitleaks can run as a pre-commit hook.

Common mistakes

Cleaning history but not rotating the key. Bots may have already copied it, so the old key must die.
Thinking a new commit that deletes .env fixes the leak. The old commit still has it.
Adding a file to .gitignore and expecting Git to stop tracking it without git rm --cached.
Making the repository private and assuming the leak is undone. Forks, clones and caches may already exist.
Committing node_modules/, making the repository huge.

What to say in the interview

".gitignore tells Git which untracked files to ignore, like .env, node_modules and build output. If I committed a secret, the first thing I do is revoke and rotate it, because once it is pushed I have to assume it is compromised. Then I remove the file from tracking with git rm --cached, add it to .gitignore, and if it was pushed, rewrite history with git filter-repo or BFG, force push, and ask the team to re-clone. To prevent it, I keep secrets in environment variables or a secret manager and use secret scanning."

Follow-up questions

Why does adding a file to .gitignore not stop Git from tracking it?
What is the difference between git rm and git rm --cached?
Where should secrets live in a deployed application?
What risks come with force pushing a rewritten history?

Go deeper

Read these once the basics above feel easy.

If the secret is only in your last unpushed commit, you do not need to rewrite the whole history. Remove the file with git rm --cached .env, add it to .gitignore, and run git commit --amend. Since nothing left your laptop, rotation is less urgent, though many teams still rotate to be safe.

#git #gitignore #security #secrets