What Must Never Reach the Repository

Put a file called .gitignore in your repository root, list patterns one per line, and Git stops offering those files. They vanish from git status, they are skipped by git add ., and they can no longer be committed by accident.

# Comments start with a hashnode_modules/          # trailing slash: directories, at any depth*.log                  # no slash: matches the file name anywhere.env                   # a plain name, also anywherebuild/                 # catches src/build/ as well as ./build/docs/*.pdf             # contains a slash, so it is anchored to the root!docs/manual.pdf       # a negation — re-include one file

Three rules do almost all the work, and the third one surprises everybody.

The first category to ignore is everything that can be regenerated. Committing it is not dangerous, just wasteful — and the waste is permanent, because history never shrinks.

# Dependencies — reinstallable from the lockfilenode_modules/vendor/.venv/__pycache__/ # Build output — regenerable from sourcedist/build/.next/*.o*.class # Editor and operating system litter.DS_StoreThumbs.db.idea/.vscode/*!.vscode/extensions.json # Logs and local databases*.log*.sqlite3 # Secrets — see the next section.env.env.local*.pemcredentials.json

Note the pairing near the editor section. .vscode/* ignores the whole folder and then !.vscode/extensions.json brings one file back, because recommending extensions to your teammates is useful while sharing your personal window layout is not.

One important exception: lockfiles are not build output. package-lock.json, yarn.lock, poetry.lock and Cargo.lock should absolutely be committed — they are what makes an install reproducible. Ignoring them is a common and expensive mistake.

This is the section that matters. If an API key reaches a commit, treat it as compromised immediately — not after you decide whether anyone saw it.

1. 1

   Deleting the file does not remove it

   Deleting it makes a new commit in which the file is absent. Every earlier commit still contains it, and git show on any of them prints it back.

2. 2

   Pushing makes it public and permanent

   On a public repository, automated scrapers find committed credentials within minutes. This is a well-documented, industrialised process, not a theoretical risk.

3. 3

   Even a private repository is not safe

   Every clone has the full history. A contributor who leaves keeps their copy, and repositories get made public later by accident more often than you would think.

4. 4

   So the only real fix is to rotate the secret

   Revoke the key at the provider and issue a new one. The old value stays in the history somewhere in the world; make it worthless instead of trying to erase it.

The prevention is boring and effective: commit an .env.example with the variable names and no values, ignore the real .env, and let GitHub's secret scanning watch your back — it is on by default for public repositories and will email you and the provider if a recognisable token lands.

DATABASE_URL=STRIPE_SECRET_KEY=RESEND_API_KEY=

This is the rule that catches everyone, once, and it is the reason the section above exists.

.gitignore only applies to untracked files. Once Git is tracking a file — once you have committed it even a single time — adding it to .gitignore changes nothing at all. Git keeps reporting it, keeps staging it, keeps committing your changes to it.

# Stop tracking it, but keep it on disk. The --cached is the whole trick.$ git rm --cached .env # For a directory$ git rm -r --cached node_modules/ # Now .gitignore takes effect. Commit the removal.$ git commit -m "Stop tracking .env; it is in .gitignore"

And note what that commit does to your teammates: it removes the file from the repository, so when they pull, the file disappears from their machines too. For a .env that is correct and they will each recreate their own. Say so in the commit message, or somebody will spend an hour wondering where their config went.

When you cannot tell whether a file is ignored and why, ask:

$ git check-ignore -v config/local.yml# .gitignore:7:*.yml    config/local.yml#  ^file      ^line ^the pattern that matched

There are three ignore files and choosing the right one is a question about who the rule is for.

$ git config --global core.excludesFile ~/.gitignore_global$ printf '.DS_Store\n.idea/\n*.swp\n' >> ~/.gitignore_global

The distinction is social, not technical. Putting .idea/ in a shared .gitignore asks every contributor to carry a rule about an editor they may not use; putting it in your global file solves it for you in every repository you will ever touch.