Free .gitignore file generator. Combine templates for Node.js, Python, Java, React, VS Code, and more. Generate project-specific ignore patterns instantly.
Tick the stacks your project uses and the .gitignore assembles itself in the panel on the right. Add anything else in the custom patterns box, then use Copy or Download — the download saves the file already named .gitignore, so you can drop it straight into your repository root. Everything runs in your browser; nothing about your project is sent anywhere.
Most people need two or three templates, not one. A typical Next.js project on a Mac wants Node.js plus Next.js plus macOS, and probably VS Code. Selecting all four is the point of the tool: overlapping patterns are deduplicated automatically, so node_modules/ or .env appears once, not four times.
34 templates in five collapsible groups. The search box filters them by name and description, so typing py narrows to Python-related entries.
| Group | Templates |
|---|---|
| Languages (10) | Node.js, Python, Java, Go, Rust, Ruby, Swift, Kotlin, .NET / C#, PHP |
| Frameworks (10) | React, Vue.js, Angular, Next.js, Django, Ruby on Rails, Spring Boot, Unity, Unreal Engine, Flutter |
| IDEs & Editors (6) | VS Code, JetBrains IDEs, Vim, Emacs, Sublime Text, Xcode |
| Operating Systems (3) | macOS, Windows, Linux |
| Other (5) | Terraform, Docker, Ansible, Logs & Cache, Secrets & Credentials |
Languages and Frameworks are expanded when the page loads; the other three groups start collapsed. Each selected template is written into the output under its own # ===== Name ===== banner, so the finished file stays readable and you can see later why a given line is there.
Node.js covers node_modules/ and jspm_packages/; build output dist/, build/, .next/ and out/; the log family *.log, npm-debug.log*, yarn-debug.log*, yarn-error.log*, pnpm-debug.log*; coverage output coverage/ and .nyc_output/; caches .npm/, .cache/, .eslintcache and *.tsbuildinfo; and the environment files .env, .env.local, .env.*.local.
Python covers __pycache__/ and *.py[cod]; virtual environments venv/, .venv/, env/ and ENV/; packaging output dist/, build/, *.egg-info/, sdist/, wheels/; test and type caches .pytest_cache/, .tox/, .nox/, .coverage, htmlcov/, .mypy_cache/; plus .ipynb_checkpoints/ for Jupyter and .python-version for pyenv.
One warning about the Python template, because it catches people out: it includes lib/ and lib64/, which come from the classic virtualenv layout. If your project has a source directory literally named lib/, that directory will be ignored and your code will silently not be committed. Check the generated output before you commit, and if you hit this, either delete that line or add !lib/ after it. The same reasoning applies to var/ and parts/.
VS Code is the most interesting one because it demonstrates the negation pattern properly. It ignores .vscode/* and then un-ignores four files that teams normally do want in version control: !.vscode/settings.json, !.vscode/tasks.json, !.vscode/launch.json and !.vscode/extensions.json. It also ignores *.code-workspace and the .history/ folder created by the Local History extension.
JetBrains IDEs — IntelliJ IDEA, WebStorm, PyCharm, CLion, Rider, Android Studio and the rest — ignores the whole .idea/ directory, plus *.iws, cmake-build-*/, out/, and several plugin leftovers such as atlassian-ide-plugin.xml and fabric.properties.
macOS is the one everybody eventually needs. It starts with .DS_Store, the Finder metadata file that appears in every directory you have ever opened in a Finder window, then covers ._* resource forks, .Spotlight-V100, .Trashes, .fseventsd, .DocumentRevisions-V100, and the files that appear on mounted AFP shares. If you work on a Mac and share a repo with anyone, add this template even for a pure Python or Go project. Windows and Linux cover the equivalent junk on those platforms.
Secrets & Credentials is worth adding to essentially every repository. It covers the .env family, credentials.json, service-account*.json, *.pem, *.key, id_rsa*, id_ed25519*, .aws/credentials, and application_default_credentials.json.
Patterns are deduplicated globally across every selected template. Node.js and Python both list build/, dist/ and .cache/; Node.js and Secrets & Credentials both list .env; Node.js and JetBrains both list out/. Whichever template you selected first supplies the line, and the later template silently omits it. Comment lines and blank lines are exempt from deduplication, so the section banners always appear even if a section ends up nearly empty.
The counter above the output reads "N patterns" and counts only real rules — comment lines and blank lines are excluded — so it tells you how many things are genuinely being ignored.
This is the single most common .gitignore problem, and no generator can fix it for you. .gitignore only applies to files Git is not already tracking. If you committed node_modules/, or a .env, or a 200 MB build artefact last week, adding the pattern today changes nothing. Git keeps tracking that file, keeps showing your edits to it, and keeps committing them.
The fix is git rm --cached, which removes the file from the index while leaving it on disk:
git rm --cached .env — untracks one file, keeps your local copy.git rm -r --cached node_modules — the -r is required for a directory.git rm -r --cached . then git add . — the sledgehammer: re-index the whole working tree so every current ignore rule is applied. Commit the result and the newly ignored files drop out.Omit --cached and git rm deletes the file from your disk as well. That is the difference between the two, and it is worth being deliberate about.
Two things this does not do. It does not remove the file from history — the previous commits still contain it, and anyone who clones the repo still gets it. Purging history needs git filter-repo or BFG plus a force-push, and every collaborator has to re-clone. And if the file was a credential that has been pushed to a shared remote, treat it as compromised and rotate it. Rewriting history is cleanup, not remediation.
| Pattern | Matches |
|---|---|
build/ | Directories named build, at any depth. A file called build is not matched. |
build | Both a file and a directory named build, at any depth. |
/build | Only build in the same directory as the .gitignore. The leading slash anchors it. |
*.log | Any file ending .log at any depth. * does not cross a /. |
logs/*.log | Log files directly inside logs/, but not in logs/2026/. |
logs/**/*.log | Log files at any depth under logs/. ** spans directory separators. |
*.py[cod] | A character class: .pyc, .pyo and .pyd. |
!important.log | Negation — re-includes a file an earlier pattern excluded. |
# comment | A comment. To ignore a file whose name genuinely starts with #, escape it as \#file. |
trailing\ space\ | Trailing spaces are stripped unless escaped with a backslash. |
Within a single .gitignore, the last pattern that matches a path decides its fate. Order therefore matters, and negations must come after the rule they are undoing. This is why the VS Code template lists .vscode/* first and the four ! lines after it — reverse them and the negations do nothing.
The trap: you cannot re-include a file if one of its parent directories is excluded. Git does not descend into an ignored directory, so it never sees the file to un-ignore it. This is exactly why the VS Code template writes .vscode/* and not .vscode/. With .vscode/ the directory itself is excluded and !.vscode/settings.json is silently dead; with .vscode/* the directory is still walked and the negation works. If you write your own negations in the custom patterns box, exclude the directory contents, not the directory.
Across files, Git consults ignore rules in this order, later sources overriding earlier ones: patterns given on the command line; then .gitignore files, with a file in a deeper directory taking precedence over one nearer the root; then .git/info/exclude, which is local to your clone and never committed; then the file named by core.excludesFile, your global ignore list. Put project rules in the committed root .gitignore, and put personal editor noise nobody else should have to read about in your global file.
The custom patterns box takes one pattern per line and appends them under a # ===== Custom Patterns ===== banner at the end of the file, after every template section. Each line is trimmed and deduplicated against everything already generated. Because they land last, custom negations correctly override template rules — adding !lib/ there really will re-include a lib/ directory the Python template excluded. Comment lines starting with # are passed through, so you can annotate your own additions.
git check-ignore -v path/to/file — tells you the exact file, line number and pattern responsible for ignoring a path. This is the answer to "why is my file not showing up".git status --ignored — lists what is currently being ignored, so you can spot anything caught by accident.git ls-files — lists what is actually tracked. If something you expected to be ignored appears here, it was committed before the rule existed and needs git rm --cached.Run git check-ignore -v once after generating a file, particularly if you selected Python or several overlapping templates. It takes seconds and catches the lib/-style surprises before they cost you an afternoon.
A .gitignore file tells Git which files and folders to exclude from version control. This prevents committing sensitive files (like .env with API keys), build artifacts (node_modules, dist), IDE settings, and OS-specific files. Every project should have one to keep your repository clean and secure.
Search or browse templates by category (Languages, Frameworks, IDEs, OS). Select all templates that apply to your project - for example, Node.js + React + VS Code + macOS. The generator combines them automatically, removing duplicates. Add any custom patterns in the text area, then copy or download your .gitignore file.
Yes! That is the main purpose of this tool. Select as many templates as you need. The generator intelligently merges patterns from all selected templates, organizes them by category, and removes duplicates. A typical project might use 3-5 templates (language + framework + IDE + OS).
The Node.js template includes: node_modules/, npm-debug.log, yarn-error.log, .npm, package-lock.json (optional), yarn.lock (optional), .env files, coverage directories, build outputs, and TypeScript build info. It covers npm, yarn, and pnpm package managers.
Generally no - lock files should be committed to ensure consistent installations across environments. Our templates include them commented out with explanations. Only ignore lock files if you have a specific reason, like a library project where you want consumers to resolve their own versions.
Environment files (.env, .env.local, .env.production) often contain sensitive information like API keys, database passwords, and secret tokens. Committing these to Git, especially public repositories, exposes your credentials. Always use .env.example with placeholder values for documentation instead.
macOS creates .DS_Store files in every folder. Windows creates Thumbs.db and desktop.ini. Linux may create .directory files. These are invisible system files that clutter repositories and differ between team members. Always include your OS template plus any others your team uses.
Use the "Custom Patterns" textarea at the bottom. Add one pattern per line. Use standard gitignore syntax: * for wildcards, / for directories, ! to negate patterns. For example: *.log ignores all log files, /temp/ ignores a root-level temp folder, !important.log keeps a specific file.
Yes! For monorepos, you can place .gitignore at the root to cover shared patterns, then add additional .gitignore files in subdirectories for package-specific rules. This generator helps create both. Patterns are relative to the .gitignore file location.
Adding patterns to .gitignore only affects untracked files. To untrack already-committed files, run: git rm --cached