How to use

Purpose

Online .gitignore generator. Pick languages / IDEs / OSes and auto-generate the .gitignore content. Based on the official GitHub gitignore repository, covering 60+ languages (Node / Python / Java / Go / Rust / C / C++ / Swift / Kotlin), 20+ IDEs (IntelliJ / VSCode / Vim / Emacs / Sublime / Eclipse), 3 major OSes (macOS / Windows / Linux), plus popular frameworks (React / Vue / Angular / Django / Rails). All generation runs locally.

Steps

Pick languages (multi-select): Node / Python / Java / Go / Rust / Ruby ...
Pick IDEs (multi-select): IntelliJ / VSCode / Vim / Eclipse ...
Pick OS (multi-select): macOS / Windows / Linux
Optional frameworks: React / Vue / Angular / Django / Rails / Laravel ...
Click Generate — combines and deduplicates
Right pane shows .gitignore content
Save as .gitignore or one-click copy
Incremental merge: paste existing .gitignore, tool dedup and complete

FAQ

Where should .gitignore go?: Project root: affects the entire repo. Any subdirectory: affects that subdir and below. User-global: ~/.config/git/ignore affects all git repos (personal preferences like IDE / OS files). Best practice: language / framework gitignore in project root (committed); IDE / OS personal files in user-global (do not pollute team repo).
Will already-committed files still be tracked after adding to .gitignore?: Yes — gitignore only affects untracked files. To untrack but keep locally: git rm --cached file (then commit). Whole directory: git rm -r --cached node_modules. Only then will .gitignore prevent future commits. Common case: accidentally committed .env or node_modules — remember to rm --cached.
Can node_modules / .DS_Store globally ignored ones go to user-global?: Yes for ~/.config/git/ignore. But node_modules is better in project .gitignore (team alignment). .DS_Store / Thumbs.db fit user-global (personal OS noise, team may use different OS).
How to handle monorepo with multiple languages?: Root .gitignore: cross-language common (IDE / OS / log / tmp). Each subproject: its own .gitignore for language-specific (package-name/node_modules / sub-app/target). Avoid too-specific entries in root (package-a/dist), as subproject migration may leave them.
Common .gitignore syntax pitfalls?: Wildcards: * does not cross directories (*.log does not match logs/a.log); ** does. Negation: !important.log re-includes an ignored file. Comments: # — whole-line only, not trailing. Directories: node_modules/ trailing slash for clarity. Position-anchored vs anywhere: /secret.txt only root secret.txt; secret.txt anywhere.

Use cases

New project init: one-click full .gitignore
Monorepo subprojects: each with its own .gitignore
Incremental completion: existing .gitignore + new language / IDE merged
Team conventions: unify IDE / OS ignore rules
Cleanup: regenerate when legacy .gitignore is messy

Use cases

New project init, monorepo subprojects, incremental completion, team conventions, legacy cleanup. Every developer’s tool. 60+ language templates, IDE / OS coverage, dedup merge, official authoritative templates are the differentiators.