Gitignore Generator
Build a .gitignore for your language, IDE, operating system and project type — live preview, deduplicated rules and custom rules with syntax checks, 100% in your browser.
Pick the rule sets that match your stack from 80+ curated sets covering programming languages,
IDEs and editors, operating systems, build tools and project types. The preview updates live as you select,
duplicate rules are removed automatically, and you can add your own patterns with a plain-English explanation
of what each one does. Copy or download the finished .gitignore and drop it in the root of your repo.
Quick-start presets
Common stacks, pre-selected in one click. You can still tweak the selection afterwards.
1. Pick your rule sets
2. Your .gitignore
3. Add custom rules
One pattern per line. Each rule is checked as you type and explained in plain English below.
Export
The JSON export lists the selected sets and every rule, handy for CI or for regenerating the file
later. The .gitignore download is the exact text shown in the preview.
How .gitignore works
Git reads .gitignore files from the repository root and from every subdirectory. A line that
matches a path tells Git to skip that path when adding files. The patterns are gitignore globs, not
regular expressions:
| Pattern | Meaning |
|---|---|
| # comment | Comment line — ignored by Git. |
| build/ | Matches any directory named build at any depth. The trailing slash restricts the match to directories. |
| *.log | Matches any file ending in .log at any depth. No slash in the pattern, so it is not anchored. |
| /dist | Matches only the top-level dist — a leading slash anchors the pattern to the location of the .gitignore file. |
| src/*.js | Matches .js files directly inside src/. A slash anywhere in the pattern anchors it to the .gitignore directory. |
| **/foo | Matches foo at any depth — ** spans directory boundaries. |
| docs/?[abcd].txt | ? matches exactly one character; [abcd] matches one character from the set. |
| !important.js | Negation — re-includes a path a later rule would otherwise ignore. It only works if the path's parent directory is not itself ignored. |
The mistakes that actually bite
- Ignoring a file that is already tracked. .gitignore only stops Git from adding
new files. If
build/is already in the repo, adding the rule changes nothing until you untrack it:git rm -r --cached build/(then commit). The--cachedflag keeps the files on disk. - Negation has limits. You cannot re-include a file if one of its parent directories
is ignored.
build/*followed by!build/keep.jsdoes not work — Git never descends intobuild/to see the negation. Negate the specific file or directory instead of the whole tree. - Slash rules. A pattern with a slash (except a leading one) is anchored to the
.gitignore's directory; without a slash it matches at any depth. So
node_modulesmatches a file or directory named node_modules anywhere, whilebuild/matches only directories. - Personal noise in a shared repo. OS and IDE files (Thumbs.db, .DS_Store, .idea/)
are personal — most teams keep them out of the project .gitignore and use a global one instead:
git config --global core.excludesFile ~/.gitignore_global. Include the OS/IDE sets here if your repo is solo or if your team wants the rules visible in-repo. - Verify with git.
git check-ignore -v path/to/filetells you exactly which rule (and which .gitignore file) is ignoring a path — the fastest way to debug a rule that seems not to work. Andgit status --ignoredshows what is currently hidden. - Over-broad wildcards.
*.jsin a JavaScript project ignores your source code. The TypeScript set does exactly this (it assumes compiled JS is a build artifact) — if you hand-write JS, remove that rule.
Suggested
