.gitignore generator
Pick a language, framework or editor. Combine as many as you like, then copy or download.
What .gitignore Actually Does
A .gitignore file sits in your project root and tells Git which files to skip when you commit. Build output, dependency folders, .env files, IDE settings — none of that belongs in version control, and this is the file that keeps it out.
One thing trips up almost everyone the first time: .gitignore only affects files Git doesn't already know about. If a file was committed before you added the rule, Git keeps tracking it regardless of what's in the ignore list. See the FAQ below for the fix.
How to Use This Generator
- Search for a language, framework, platform, or editor. Try "node", "python", "android", "vscode".
- Click to select. It shows up as a chip and the rules appear in the preview instantly. Stack as many as you need — most real projects use two or three (a language, a framework, an editor).
- Remove anything you don't need by clicking the × on its chip.
- Add custom rules in the box below if your project needs something the templates don't cover.
- Copy or download, then commit the file to your project root.
Runs entirely in your browser — nothing you type or select gets sent anywhere.
Ready-to-Use Examples
React (Create React App / Vite)
node_modules/
build/
dist/
.env
.env.local
npm-debug.log*
yarn-error.log*
.eslintcachenode_modules alone can run hundreds of megabytes and is fully reproducible from package.json — there's never a reason to commit it. The .env files matter more: that's usually where API keys end up.
Python
__pycache__/
*.py[cod]
*.so
build/
dist/
*.egg-info/
.venv/
venv/
.env
.pytest_cache/
.mypy_cache/
.ipynb_checkpoints/__pycache__ regenerates every time you run a script, so tracking it is pointless. If you use a virtual environment, keep it out too — it's tied to your machine and rebuilds instantly from requirements.txt.
Node / Express backend
node_modules/
dist/
.env
.env.local
.env.*.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
coverage/
.cache/coverage/ shows up if you run test coverage reports. It regenerates every run, same logic as any build folder.
Mistakes That Actually Happen
| Mistake | Fix |
|---|---|
| Adding a rule after the file's already committed | git rm --cached filename, then commit |
Missing the trailing slash on a folder (build instead of build/) |
Always slash folder patterns |
| Grabbing a template from the wrong stack | Skim it first — a folder like lib means different things in different ecosystems |
| Ignoring lock files by accident | Keep package-lock.json / yarn.lock tracked so everyone installs the same versions |
| Assuming .gitignore protects a secret that's already committed | It doesn't. Rotate the credential immediately — see below |
That last one is the only mistake on this list that actually costs you something. Everything else just makes your repo messier.
If You Already Committed a Secret
Adding the file to .gitignore now doesn't erase it from history — Git keeps every past version of every file, so the key is still sitting in an old commit whether or not you're tracking it going forward. Treat the credential as burned: rotate it, revoke the old one. If you also want it out of the repo's history entirely, a tool like BFG Repo Cleaner can strip it, but that rewrites commit hashes for everyone on the project, so coordinate before running it.
If you're not sure what else you might have force-pushed, rebased, or otherwise buried in your history, our Git undo guide covers recovery for most of the things people panic about.
FAQ
Do I need a different .gitignore for every project?
The contents should match what the project actually generates — a Python repo and a React repo produce different junk. If you find yourself reusing the same combination across projects, save it somewhere instead of rebuilding it each time.
Why is my .gitignore not working?
Almost always: the file was already committed before you added the rule. Run git check-ignore -v filename — it tells you exactly which rule in which file is or isn't matching.
Should I commit the .gitignore file itself?
Yes. It needs to be shared so the whole team's setup stays consistent — otherwise everyone rebuilds their own version and you lose the point of having one.
Can one .gitignore cover multiple languages in the same repo?
Yes — combine both sets of rules in one file. Git just matches whatever applies, regardless of how many patterns or where they came from. This is the main reason to stack templates in the generator above instead of writing each ecosystem's rules from memory.
Is there a global .gitignore for OS or editor files?
Yes, and it's worth setting up once: git config --global core.excludesfile plus a path to a file on your machine. Personal files like .DS_Store or editor settings then stay out of every repo automatically, and your per-project .gitignore stays focused on the project itself.
Does .gitignore slow Git down?
No — the opposite. Every ignored pattern is one less thing Git checks on git status or git add. A well-maintained .gitignore makes day-to-day commands faster, especially on projects with large dependency folders.