🚫 Gitignore Generator: Build a .gitignore File for Any Stack
By Shihab Mia · Updated 2026-07-17
Tick every language, framework, OS and editor your project uses. Rules are combined and deduplicated.
Select at least one stack to build your .gitignore file.
A .gitignore file tells Git which paths to leave untracked: build output, dependency folders like node_modules, virtual environments, secrets in .env, and editor or OS junk such as .DS_Store and Thumbs.db. This gitignore generator builds that file for you. Tick the stacks your project actually uses (Node, Python, Java, macOS, Windows, VS Code, JetBrains), and it stitches the matching rule sets into one file with a comment header per section, strips duplicate patterns, and gives you Copy and Download buttons. Save the result as .gitignore in your repository root and commit it. Everything runs in your browser, so no code, path names, or project details leave your machine.
What is the Gitignore Generator?
Git tracks every file in your working directory unless you tell it not to, and that default is almost never what you want. Compiled artifacts, the node_modules folder, Python virtual environments, log files, coverage reports, and machine-specific editor settings do not belong in a shared repository. They bloat the history permanently, produce merge conflicts that nobody can resolve meaningfully, slow down clones, and are a common route for credentials to leak into a public repo. A .gitignore file is a plain-text list of patterns that Git consults when deciding whether a path is worth tracking. Each non-empty, non-comment line is either a glob pattern (*.log), a directory rule (node_modules/), an anchored path (/config.local.json), or a negation (!keep.txt) that re-includes something an earlier rule excluded.
Most real projects need rules from three separate sources at once, and this is the point most hand-written .gitignore files get wrong. First comes the language or runtime: Node drops node_modules and dist, Python leaves __pycache__ and .venv, Java produces target/ and *.class. Second comes the operating system, which litters directories with files that have nothing to do with your code: macOS writes .DS_Store into every folder Finder touches, Windows writes Thumbs.db and Desktop.ini. Third comes the editor or IDE, which stores workspace state in .vscode or .idea. Miss any one of the three and your teammates will keep opening pull requests full of noise. Combining curated snippets, rather than recalling patterns from memory, is why a generator is faster and more accurate than copying an old file across.
Pattern syntax has a few rules worth knowing because they explain nearly every case where an ignore rule seems not to work. A pattern with no slash, such as .log, matches at any depth. A pattern with a leading or embedded slash is anchored relative to the .gitignore file that contains it, so /build only matches build in that directory, not src/build. A trailing slash restricts a rule to directories. A leading matches across directories (/logs), and a trailing / matches everything inside a path (docs/*). Per the official Git documentation, an asterisk matches anything except a slash, and a question mark matches any single character except a slash. Within one .gitignore file the last matching pattern wins, which is what makes negations work at all, and .gitignore files in nested directories take precedence over ones higher up the tree.
The single most important limitation, and the reason most people search for a gitignore generator only after something has gone wrong, is that .gitignore applies to untracked files only. If a file is already in the index, Git keeps tracking it and no ignore rule will change that. The fix is git rm --cached <path> (add -r for a folder), which removes the file from tracking while leaving it on disk, followed by a commit. The second most important limitation is that ignoring a secret after it has been committed does nothing to the history: the value is still recoverable from every clone. In that case rotate the credential first, then consider rewriting history with a tool like git filter-repo. Ignoring is a prevention mechanism, not a cleanup mechanism.
This tool keeps the output tidy in two deliberate ways. Every stack you select is emitted under its own comment header, so six months later you can see exactly which section a pattern came from and edit it with confidence instead of deleting a line and hoping. And the generator deduplicates by exact pattern text: if you pick Python and Java, both of which ignore build/, the line appears once, under whichever stack came first. That matters more than it sounds, because a .gitignore full of repeated lines is a file nobody maintains. The result is a starting point, not a finished artifact. Add the handful of project-specific paths only you know about, such as a local data dump, a generated OpenAPI client, or a fixtures cache, under a comment of your own.
One extra habit worth adopting alongside the generated file: keep personal preferences out of the project. Rules that belong to you rather than the repository, such as your editor of choice or an OS you happen to use, can go in a global gitignore configured with git config --global core.excludesFile ~/.gitignore_global. Teams often disagree about whether .vscode or .idea belongs in the repo, and a global file ends that argument without anyone having to win it. Use the project .gitignore for what every contributor must ignore, and the global one for what only your machine produces.
When to use it
- Starting a new repository and wanting a correct .gitignore in seconds instead of copying a half-remembered one from an old project.
- Adding a second language or framework to an existing repo and needing the extra ignore rules merged in without duplicated lines.
- Cleaning up a repository where committed build artifacts or .idea folders keep producing noisy diffs and pointless merge conflicts.
- Standardising .gitignore files across a team so every contributor ignores the same OS and IDE clutter, whatever machine they use.
- Preparing a repository to go public and wanting .env, credential files, and local config excluded before the first push.
- Building a starter template or scaffolding script and needing a reliable base .gitignore to ship with it.
How to use the Gitignore Generator
- Tick every stack your project uses: the language or runtime, the operating system you develop on, and your code editor or IDE.
- Use Select all or Clear all to toggle everything at once when that is faster than picking individually.
- Read the combined, deduplicated .gitignore in the output box and check each headed section makes sense for your project.
- Click Copy to put it on the clipboard, or Download to save it directly as a .gitignore file.
- Place the file in the root of your repository, named exactly .gitignore with the leading dot and no extension.
- Add any project-specific paths of your own under a new comment header, then commit the file.
- If something you just ignored is already tracked, run git rm -r --cached <path> and commit so the rule takes effect.
Formula & method
Worked examples
A Node project on macOS, edited in VS Code. You select Node, macOS, and VS Code.
- Node contributes node_modules/, dist/, build/, coverage/, .env and *.tsbuildinfo.
- macOS contributes .DS_Store, ._*, .Spotlight-V100 and other Finder artifacts.
- VS Code contributes .vscode/* with negations like !.vscode/settings.json to keep shared config tracked.
- No pattern is shared between the three stacks, so nothing is dropped as a duplicate.
- The file is written with three labelled sections in the order you ticked them.
Result: A .gitignore with three headed sections covering dependencies, OS junk, and editor files, roughly 25 lines.
A polyglot repo with a Python backend and a Java service. You select Python and Java, and both ignore build/.
- Python is processed first and emits __pycache__/, *.pyc, .venv/, *.egg-info/, .pytest_cache/, dist/ and build/.
- Java is processed next and would emit *.class, *.jar, target/, .gradle/, bin/ and build/.
- The generator sees build/ was already emitted under Python, so it omits the duplicate under Java.
- No other Java pattern overlaps with Python, so build/ is the only line removed.
- Every remaining Java pattern is new and is kept under the Java header.
Result: Both stacks are covered with build/ appearing exactly once, under the Python section.
You want to ignore a logs folder but keep one placeholder file inside it, so the folder survives a clone.
- Writing logs/ then !logs/.gitkeep does not work: once the directory itself is excluded, Git never looks inside it.
- Instead ignore the contents rather than the directory: logs/*.
- Then add the negation on the next line: !logs/.gitkeep.
- Order matters, because within one file the last matching pattern wins.
- Commit the empty .gitkeep file so the directory exists for everyone who clones the repo.
Result: logs/ is present and empty in every clone, while its contents stay untracked.
Stacks available in this gitignore generator and what each one ignores
| Stack | Typical patterns ignored | Why |
|---|---|---|
| Node | node_modules/, dist/, build/, coverage/, .env, *.tsbuildinfo | Reinstallable dependencies, generated bundles, secrets |
| Python | __pycache__/, *.pyc, .venv/, *.egg-info/, .pytest_cache/ | Bytecode caches, virtual environments, packaging output |
| Java | *.class, *.jar, target/, .gradle/, bin/, .classpath | Compiled classes and Maven or Gradle build directories |
| macOS | .DS_Store, ._*, .Spotlight-V100, .Trashes | Finder metadata written into any folder you open |
| Windows | Thumbs.db, Desktop.ini, $RECYCLE.BIN/, *.lnk | Explorer thumbnail caches and shell metadata |
| VS Code | .vscode/* with !settings.json, !tasks.json, !launch.json | Personal workspace state out, shared project config kept |
| JetBrains | .idea/, *.iml, out/, cmake-build-*/ | IntelliJ, PyCharm and WebStorm project state |
.gitignore pattern syntax reference
| Pattern | Meaning |
|---|---|
| node_modules/ | Match a directory and everything inside it, at any depth |
| *.log | Match every file ending in .log, in any folder |
| /secret.txt | Match secret.txt only next to this .gitignore, not in subfolders |
| build/ | Trailing slash means directories only, not a file named build |
| **/temp | Match temp at any depth, equivalent to a bare pattern with no slash |
| docs/** | Match everything inside docs, at unlimited depth |
| debug?.log | Question mark matches exactly one character except a slash |
| *.[oa] | Character class: matches file.o and file.a but not file.c |
| !keep.log | Negation: re-include keep.log that *.log would have ignored |
| \#file.txt | Backslash escape for a filename that literally starts with # |
| # comment | A line starting with # is a comment and matches nothing |
Git commands you will need alongside the generated file
| Command | What it does |
|---|---|
| git rm -r --cached path/ | Untrack an already-committed folder while keeping it on disk |
| git check-ignore -v file | Show exactly which .gitignore line is excluding a given path |
| git status --ignored | List ignored files so you can confirm the rules match what you expect |
| git add -f file | Force-add a single file despite an ignore rule, one time only |
| git config --global core.excludesFile ~/.gitignore_global | Point Git at a personal global ignore file for OS and editor junk |
| git clean -nXd | Dry run listing ignored files that would be deleted; swap -n for -f to delete |
Common mistakes to avoid
- Adding .gitignore after the files are already committed. A .gitignore only affects untracked files. If node_modules or a build folder is already in the index, Git keeps tracking it and the new rule appears to do nothing. Run git rm -r --cached node_modules, then commit. The files stay on disk and the ignore rule applies from that commit forward.
- Ignoring a folder but expecting one file inside to survive. Git does not descend into an excluded directory, so a negation like !logs/keep.txt after logs/ never fires. Ignore the contents instead: write logs/* on one line and !logs/keep.txt on the next. This is the single most common .gitignore bug.
- Assuming an ignore rule erases a leaked secret. Adding .env to .gitignore does nothing to a credential you already pushed. The value remains in the history and in every clone and fork. Rotate the exposed key immediately, then rewrite history with git filter-repo if the repo is private enough for that to help.
- Using Windows backslashes in patterns. Git always uses forward slashes in .gitignore paths, even on Windows. Write build/output, not build\output. A backslash is an escape character in this syntax, so the rule will silently fail to match rather than error.
- Putting personal editor preferences in the project file. If only you use vim, .swp does not belong in the shared .gitignore. Rules that depend on your machine or tooling go in a global ignore file set with git config --global core.excludesFile. The project file should list what every contributor must ignore.
- Guessing at a rule instead of asking Git which line matched. When a file is ignored and you do not know why, do not add more patterns. Run git check-ignore -v path/to/file and Git prints the exact file, line number, and pattern responsible. It also reports nothing at all if no rule matches, which is itself the answer.
Glossary
- .gitignore
- A plain-text file listing patterns for paths Git should leave untracked. Usually sits in the repository root, but can appear in any directory.
- Pattern
- A single meaningful line in .gitignore, such as *.log or node_modules/, that Git matches against candidate paths.
- Glob
- Wildcard matching syntax where * matches any run of characters except a slash, ? matches one such character, and ** crosses directory boundaries.
- Negation
- A pattern starting with ! that re-includes a path an earlier rule excluded. It cannot rescue a file whose parent directory is already excluded.
- Anchored pattern
- A pattern containing a slash anywhere except at the end, which is matched relative to the .gitignore file rather than at any depth.
- Untracked file
- A file in your working directory that Git is not following. Only untracked files are affected by .gitignore.
- Index (staging area)
- The list of files Git is tracking for the next commit. Once a path is in the index, .gitignore stops applying to it.
- Global gitignore
- A personal ignore file set with core.excludesFile that applies to every repository on your machine, for OS and editor junk.
- Repo root
- The top folder of the repository, where the .git directory lives and where the main .gitignore normally sits.
Frequently asked questions
What is a .gitignore file?
A .gitignore file is a plain-text file in your repository listing patterns for paths Git should not track, such as build output, dependency folders, secrets, and OS or editor junk. Keeping those out of version control shrinks the history, removes meaningless merge conflicts, and prevents credentials leaking. Each line is one pattern, blank lines are skipped, and lines starting with # are comments.
How do I create a .gitignore file?
Select the stacks your project uses in the generator above, click Download, and save the file as .gitignore in your repository root, then commit it. By hand, create a file named exactly .gitignore with a leading dot and no extension. On Windows, File Explorer may resist a name starting with a dot, so create it from your editor or run type nul > .gitignore in the terminal.
Where do I put the generated .gitignore file?
In the root of your repository, next to the .git directory. Rules there apply to that folder and every subfolder. You can also place additional .gitignore files in subdirectories for narrower rules, and the closest file to a path takes precedence over ones further up the tree.
Why is my .gitignore not working?
Almost always because the file is already tracked. .gitignore only applies to untracked files, so a path committed before you added the rule keeps being tracked. Run git rm -r --cached <path> and commit. If that is not it, run git check-ignore -v <path>, which prints the exact file and line number of the rule matching that path, or nothing if no rule matches.
How do I ignore a file that is already committed?
Add the pattern to .gitignore, then run git rm --cached <file> (add -r for a folder) and commit. This removes the file from Git tracking while leaving it on your disk. Everyone else will see the file deleted on their next pull, so warn your team first if the file is something they need locally.
How are duplicate rules handled by this gitignore generator?
When two selected stacks share a pattern, such as build/ in both Python and Java, the generator emits it once, under the first stack that uses it. Duplicate lines are harmless to Git but make the file harder to maintain, so removing them keeps the output short and readable.
What is the difference between .gitignore and a global gitignore?
A project .gitignore is committed to the repository and applies to every contributor. A global gitignore is personal, is not committed, and applies to all repositories on your machine. Set one with git config --global core.excludesFile ~/.gitignore_global. Use the project file for language and framework rules, the global file for your OS and editor.
Should I commit .vscode or .idea to my repository?
Ignore most of it, keep the shared parts. The VS Code section here ignores .vscode/* but negates settings.json, tasks.json and launch.json, so team-wide formatting and debug configs stay tracked while personal state does not. For JetBrains the convention is stricter: ignore .idea/ and *.iml entirely, since those files contain absolute local paths.
Why does .gitignore ignore a folder but not the files inside it?
That is expected. Once a directory is excluded, Git does not descend into it, so nothing inside can be re-included by a later negation. To keep one file, ignore the contents rather than the folder: use logs/* followed by !logs/keep.txt. Order matters because the last matching pattern wins.
Can I edit the generated file afterwards?
Yes, and you should. The generator covers the clutter that is common to a stack, but every project has paths only you know about, such as a local data dump or a generated client. Add those under a comment header of your own, delete any section you do not need, and commit the result like any other source file.
Sources
- gitignore(5): pattern format and order of precedence , Git official documentation
- github/gitignore: a collection of useful .gitignore templates , GitHub
- git-rm: using --cached to untrack committed files , Git official documentation
- git-check-ignore: debugging which pattern matched a path , Git official documentation