WHAT IT DOES
Fixed fragments, not a generated guess.
Search across a hundred and eighty maintained sections — languages and runtimes, frameworks and platforms, build and test tooling, infrastructure, editors, AI agents — and get a .gitignore assembled from fixed fragments. Every rule is checked against the documentation of the tool it belongs to, and a section wide enough to hide something you meant to commit says so before you choose it. Choosing a framework brings what it depends on: Expo brings React Native and Node.js, Flutter brings Dart and both native platforms. Every one of those is named on screen and in the file rather than added quietly. The same selection produces the same file every time, whatever order you choose the sections in.
Why use it?
Use it to assemble ignore rules for a project's actual tools while reviewing the rules that might also hide intentional source or team configuration.
How to use this tool
- Search for your stack, select relevant sections, and review automatically implied dependencies and risk labels.
- Generate the file, then read the comments before saving it as .gitignore. Remove or narrow patterns that cover files your team keeps.
- Check representative paths with git check-ignore -v. For example, verify both a private .env and the .env.example you intend to commit.
- Remember that ignore rules do not remove already tracked files or erase secrets from Git history. Review repository state separately.
Details and limitations
- Sections are written in a fixed order rather than the order they were selected, so two people with the same choices produce identical files.
- A framework brings the runtime it needs. Choosing Next.js writes the Node.js section too, marked in the picker and named in the file as having arrived that way, so nothing appears in the output that the output does not account for.
- Choosing something outright outranks having it implied: pick Node.js as well as Next.js and it is written once, as your choice rather than as a consequence.
- AI agent files are kept out of version control by default — prompts, project instructions, and local state alike, so CLAUDE.md and .claude/ are ignored along with the caches. That is a default rather than a verdict: every rule is commented in the output, and deleting one line shares that file with your team.
- A technology only becomes a section if it contributes patterns nothing else does. React on top of Vite adds nothing to ignore, so searching for it finds Node.js instead of writing a React section that repeats dist/. Aliases mean the search covers far more names than there are sections.
- Every section is rated for how much of a judgement it is making, and the rating is shown before you choose it and written into the file itself. Most are unrated: generated output with a strong convention behind it. The rest say “project-dependent” or “broad patterns”, because a rule that can hide work you meant to commit should say so before it does.
- Repeated rules across sections are left alone. build/ under three ecosystems is what makes the file readable, and a deduplicator would eventually move a negation such as !.vscode/settings.json away from the pattern it depends on.
- Rules that are a project decision are included but left commented out: vendor/ for Go, Cargo.lock for a Rust library, pubspec.lock for a Dart package, Pods/ for an Xcode project. A generator that silently picks a side is wrong for half the people using it.
- The environment section ignores .env and .env.* while re-including .env.example, with the negation written after the pattern it re-includes, which is the order git requires.
- The VS Code section follows the editor's own recommendation, ignoring .vscode/ but keeping settings.json, tasks.json, launch.json, and extensions.json.
- Every generated file names the fragment date it was built from, so a file in a repository can be compared against a later version of this page.
- Download writes the file from your browser with an object URL; nothing is uploaded and nothing is generated on a server.