How it works
A good .gitignore is written once and maintained never: it keeps dependencies, build output, OS droppings, editor state and secrets out of the repository from day one. The mistakes are always the same — committed node_modules, a .env pushed with real credentials, .DS_Store noise in every diff, or a build directory that turns every pull request into a conflict generator.
The generator composes the file from curated templates instead of a blank page: language stacks (Node, Next.js/React, Python, Django, Go, Rust, Java, PHP/Composer, Laravel, Ruby/Rails), frameworks with known leaky paths (WordPress with wp-config.php and uploads), operating systems (macOS, Windows, Linux), editors (VS Code, JetBrains, Vim), plus Terraform, Docker and a dedicated secrets block that ignores every .env variant while keeping .env.example.
Tick what applies, and the output assembles with labeled sections — readable months later when someone asks why a rule exists. Copy it or download the file directly; the line count excludes section headers so you see how many real rules you are shipping.
Everything happens locally — no fetching of remote templates, so the file is exactly what you selected, reproducible offline and safe to build for private stacks.
Worked example
A typical web project — Node API with a Python worker, developed on macOS in VS Code — needs four templates plus the secrets block.
| Template | Key rules | Prevents |
|---|---|---|
| Node.js | node_modules/, .env, dist/ | Dependencies and build output in the repo. |
| Python | __pycache__/, .venv/, *.egg-info/ | Bytecode and virtualenvs committed by mistake. |
| macOS | .DS_Store, ._* | Finder metadata polluting every directory. |
| Env & secrets | .env, *.pem, credentials.json | The one mistake that becomes an incident. |
- Pick your stacks: Languages and frameworks first — they carry the biggest directories.
- Add OS and editors: macOS, Windows, VS Code or JetBrains rules kill diff noise.
- Never skip secrets: The Env & secrets template is the one that prevents incidents.
- Copy or download: Drop the file at the repo root and verify with git check-ignore.
The composed file is labeled per section: when a teammate asks why .env.example is committed while .env is not, the secrets section documents the convention in place.
Common errors and edge cases
- Ignoring after committing. .gitignore only affects untracked files — a committed .env stays in history. git rm --cached it, rotate the secret, and scrub history if it ever contained real credentials.
- Ignoring .env.example. The template file must be committed; it documents required variables. The secrets template keeps it via a negation rule.
- Global ignores nobody agreed on. Editor and OS rules belong in each developer's global ~/.gitignore, but teams standardize on repo-level rules — fewer surprises for new contributors.
- Over-broad patterns. *.log can hide production debugging files you actually want to keep examples of. Prefer directory-scoped rules like log/*.log.
- Forgetting the build pipeline. If CI builds in the repo, ignore the same artifacts there — otherwise CI artifacts leak into the working tree and confuse status checks.
Code equivalents
The commands that fix the two mistakes .gitignore alone cannot: untracking committed files and auditing what the repo already holds.
| Task | Command |
|---|---|
| Untrack a committed file | git rm --cached .env && git commit -m 'stop tracking .env' — then rotate the secret. |
| Audit for secrets | git log -p | grep -iE 'password|secret|api_key' — check history, not just the working tree. |
| Verify a rule | git check-ignore -v node_modules/foo — shows which line ignores the path. |
Related tools
Frequently asked questions
I committed .env before adding it to .gitignore — now what?
git rm --cached .env and commit, then rotate every credential in it immediately: anything that was committed must be considered public. For real secrets, scrub history with git filter-repo as well.
Should editor and OS rules live in the repo's .gitignore?
Purists put them in a global ~/.gitignore; pragmatic teams put them in the repo so every contributor gets them. Either works — duplication between the two is harmless.
Why keep .env.example if .env is ignored?
The example documents required variables without values, so a new developer knows what to configure. Ignoring both leaves the setup undocumented; the template's negation rule keeps the example tracked.
Does .gitignore apply retroactively to history?
No. It only affects untracked files going forward. Files committed before the rule stay in history until explicitly removed with git rm --cached and a commit.
How do I check why a file is being ignored?
git check-ignore -v path/to/file prints the exact .gitignore line responsible — the fastest way to debug an over-broad pattern.
Privacy note
All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.