.gitignore generator
Pick a language, framework or editor. Combine as many as you like, then copy or download.
Add custom rules
What is .gitignore?
If you have ever pushed a project to GitHub and then noticed your entire node_modules folder sitting there, you already know why .gitignore exists. It is a plain text file that sits in the root of your project and tells Git which files and folders to skip when you commit your code.
Every project generates files that have no business being in version control. Build outputs, dependency folders, environment variables with your API keys, IDE settings, cache files, log files. None of that belongs in your repository. A .gitignore file is simply a list of patterns, one per line, and Git quietly ignores anything that matches.
Note: a .gitignore file only affects files Git does not already know about. If a file was committed before you added it to the list, Git keeps tracking it regardless. More on this in the FAQ below.
Without it, your repo gets bloated, your teammates end up pulling gigabytes of junk they do not need, and worse, you risk accidentally leaking secrets like database passwords or API tokens. Once a secret is in your Git history, deleting the file later does not remove it. It is still sitting in an old commit that anyone can dig up.
Why .gitignore matters more than people think
New developers often treat .gitignore as an afterthought, something you add once and forget about. In practice it affects three things that matter on every real project:
- Repository size and speed. A repo full of build artifacts and dependency folders takes longer to clone, longer to push, and longer to search through. On a team, this slows everyone down, not just you.
- Security. Config files, .env files, and credential files often get created automatically by frameworks and tools. If they are not ignored from day one, it is extremely easy to commit them without noticing, especially with a command like
git add .that stages everything at once. - Clean collaboration. When your repo only contains source code, anyone reviewing a pull request sees exactly what changed in the actual logic. When it is cluttered with regenerated files, diffs become noisy and reviews take longer.
How to use the .gitignore generator tool
The tool above is built to save you from writing these files by hand or hunting through old Stack Overflow answers. Here is exactly how to use it:
- Search for what you need. Type into the search box at the top. You can search by language (Python, Java), framework (React, Laravel), platform (Android, iOS), or tool (Docker, VS Code). The list filters instantly as you type.
- Select your templates. Click any item in the list, or its checkbox. It gets added as a chip above the search box, and the rules for it appear instantly in the preview below. You are not limited to one, most real projects need two or three, for example a language, a framework, and your code editor.
- Remove anything you do not need. Click the small x on any chip to remove that template. The preview updates immediately, so you can experiment freely without breaking anything.
- Add custom rules if needed. Not every project fits neatly into a template. Open the "Add custom rules" section and type your own patterns, one per line. They get appended to the bottom of the generated file automatically.
- Copy or download. Click "Copy to clipboard" and paste it into a new .gitignore file in your editor, or click "Download .gitignore" to save the file directly, ready to drop into your project folder.
- Commit it. Save the file in your project root, the same folder that contains your .git directory, then commit it like any other file. From that point forward, Git ignores everything listed inside it.
The tool works entirely in your browser, so nothing you type or select gets sent anywhere. There is also a "Clear all" button if you want to start over from scratch.
Gitignore Examples
React project
A typical React app created with Create React App or Vite generates a lot of disposable files. Your .gitignore should usually cover the dependency folder, build output, and any local environment files that hold sensitive keys.
node_modules/
build/
dist/
.env
.env.local
npm-debug.log*
yarn-error.log*
.eslintcacheThe node_modules folder alone can be hundreds of megabytes, and it is fully reproducible from your package.json, so there is never a good reason to commit it. The .env files are just as important to exclude since they often hold API keys or secret tokens you do not want sitting in a public repo.
Python project
Python projects come with their own set of clutter, mostly from compiled bytecode, virtual environments, and testing caches.
__pycache__/
*.py[cod]
*.so
build/
dist/
*.egg-info/
.venv/
venv/
.env
.pytest_cache/
.mypy_cache/
.ipynb_checkpoints/The __pycache__ folders and .pyc files are auto-generated every time you run your scripts, so tracking them is pointless. If you work with virtual environments (and you should), folders like venv or .venv need to stay out of version control too, since they are tied to your local machine and can be recreated instantly with a requirements file.
Node project
For a general Node.js backend project, whether it is Express, NestJS, or something custom, the essentials look similar to the React case but with a slightly different focus.
node_modules/
dist/
.env
.env.local
.env.*.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
coverage/
.cache/The coverage folder shows up if you run test coverage reports, and it regenerates every time you run your test suite, so there is no reason to keep it in the repo. Same logic applies to any build or dist folder your bundler creates.
Common .gitignore mistakes to avoid
Most .gitignore problems come down to a handful of repeated mistakes.
| Mistake | Why it happens | How to fix it |
|---|---|---|
| Adding a pattern after the file is already committed | .gitignore only affects untracked files | Run git rm --cached filename, then commit again |
| Forgetting the trailing slash on folders | Writing build instead of build/ |
Add a trailing slash to any folder pattern to be explicit |
| Copying a template from the wrong project type | A folder like lib means different things in different ecosystems | Skim the template before applying it, do not assume every line fits |
| Ignoring lock files by accident | package-lock.json or yarn.lock get lumped in with other generated files | Keep lock files tracked so everyone installs the same dependency versions |
| Assuming .gitignore protects secrets already exposed | The old commit still holds the secret even after the file is ignored | Rotate the credential immediately and clean history if needed |
Frequently Asked Questions
Do I need a different .gitignore for every project?
Not exactly a different one from scratch, but yes, the contents should match what your specific project actually generates. A Python project and a React project produce completely different junk files, so their ignore lists will look different. That is exactly why this generator lets you mix and match templates instead of writing everything manually. If you work across many similar projects, it is worth saving your most common combination somewhere so you are not rebuilding it every time.
Can I edit a .gitignore file after creating it?
Yes, any time. It is just a plain text file, so you can open it in any code editor, add new lines, remove old ones, and save it like any other file in your project. Just remember that changes only affect files Git is not already tracking. If you add a new rule for a file that was committed months ago, that old file stays tracked until you explicitly remove it with a command like git rm --cached filename, followed by a new commit.
Why is my .gitignore not working?
The most common reason, by far, is that the file you are trying to ignore was already committed before you added it to .gitignore. Another possibility is a typo in your pattern, or a missing trailing slash on a folder name. You can check exactly why a file is or is not being ignored by running git check-ignore -v filename in your terminal, which tells you precisely which rule in which file is matching it.
Should I commit my .gitignore file itself?
Yes, absolutely. Unlike the files it lists, the .gitignore file itself should be committed and shared with your team so everyone's local setup stays clean and consistent. If you do not commit it, every teammate has to recreate their own version, and you lose the whole point of having one shared source of truth for what gets tracked.
Can I use one .gitignore for multiple languages in the same project?
Yes. If your project mixes a Python backend with a React frontend, for example, just combine both sets of rules in the same file. Git does not care how many patterns you list or where they came from, it just matches whatever applies. This is one of the most useful things about using a generator like the one above, since you can stack multiple templates together in seconds instead of researching each ecosystem's conventions separately.
Is there a global .gitignore for things like my operating system or editor?
Yes, and it is a smart move. Instead of adding macOS or VS Code files to every single project's .gitignore, you can set up a global ignore file on your machine using git config --global core.excludesfile followed by a path to a file on your computer. That way, personal system files like .DS_Store or editor settings never show up as untracked changes across any of your repositories, and your per-project .gitignore files stay focused purely on things specific to that project.
What happens if I accidentally commit a secret before adding it to .gitignore?
Adding the file to .gitignore afterward stops future commits, but it does not erase the secret from your project's history, since Git keeps every past version of every file. The correct response is to treat the credential as compromised right away and rotate it, meaning generate a new API key or password and revoke the old one. If you also want to remove the old file from your Git history entirely, tools built specifically for that purpose, like BFG Repo Cleaner, can rewrite history and strip it out, though this should be done carefully since it changes commit hashes for everyone working on the repo.
Does .gitignore slow down Git or affect performance in any way?
No, if anything it does the opposite. Every pattern in .gitignore tells Git to skip checking that file or folder for changes, which means less work when you run commands like git status or git add. A well maintained .gitignore actually makes your day to day Git workflow faster, especially on projects with large dependency folders or generated build directories that would otherwise slow down every status check.