.gitignore Generator
Pick your stack and get a ready-to-use .gitignore instantly
Language
Framework
Tool
Editor
OS
### Node.js ### node_modules/ npm-debug.log* yarn-debug.log* yarn-error.log* pnpm-debug.log* .pnp/ .pnp.js dist/ build/ coverage/ *.tsbuildinfo ### VS Code ### .vscode/* !.vscode/settings.json !.vscode/tasks.json !.vscode/launch.json !.vscode/extensions.json *.code-workspace ### macOS ### .DS_Store .AppleDouble .LSOverride ._* .Spotlight-V100 .Trashes
About this tool
The .gitignore Generator builds a combined .gitignore file from curated templates for languages, frameworks, editors, and operating systems. Select Node.js, Python, VS Code, macOS — or any combination — and get a ready-to-use file with clearly labeled sections for each stack you picked. Starting a repository without a proper .gitignore leads to committed node_modules folders, IDE config files, and OS junk files that clutter every future diff. This generator front-loads that decision so it's done correctly from the first commit.
When to use it
- →Setting up a new repository's .gitignore correctly from the very first commit
- →Combining multiple stacks — e.g. a Python backend with a Node.js frontend — into one file
- →Adding editor and OS ignores (VS Code, JetBrains, macOS, Windows) to an existing project that's missing them
- →Quickly checking what a standard .gitignore for a given language typically excludes
Tips
- ◆Combine categories freely — most real projects need at least a language template, an editor template, and an OS template together.
- ◆If you're already tracking a file that a new .gitignore excludes, adding it to .gitignore alone won't stop tracking it — run git rm --cached <file> first.
- ◆Re-generate and diff against your existing .gitignore periodically — new tooling (a new editor, a new framework) often needs its own ignore rules added later.
Frequently asked questions
Why doesn't adding a file to .gitignore remove it from the repository?
.gitignore only affects untracked files — it tells Git which new files to ignore, not what to do with files already being tracked. If a file was committed before you added it to .gitignore, Git keeps tracking it. Untrack it first with git rm --cached <file> (this removes it from tracking but keeps it on your disk), then commit — the .gitignore rule takes effect from that point forward.
Should I commit a .gitignore file to a public repository?
Yes, always — a .gitignore file itself contains no sensitive information (it just lists patterns), and committing it ensures every contributor gets the same ignore rules automatically instead of relying on their own local, uncommitted ignore list.
What's the difference between .gitignore and a global gitignore?
A repository's .gitignore is committed and shared with everyone who clones it — use it for anything specific to the project (build output, dependency folders). A global gitignore (configured via git config --global core.excludesfile) applies to every repository on your machine and is not shared — use it for personal editor/OS files so you don't have to add them to every project's .gitignore individually.
Why is node_modules ignored instead of committed?
node_modules can be regenerated exactly from package.json and the lockfile via npm install, and it's often hundreds of megabytes of third-party code that changes with every dependency update. Committing it would bloat the repository's history permanently and create massive, unreviewable diffs on every install. The lockfile (package-lock.json / yarn.lock) is committed instead — that's what makes the install reproducible.