.gitignore Generator and Tester

Choose the presets your project needs, then test representative paths against the output. Matching covers common patterns; confirm edge cases with Git.

Runs locally in your browser
This tool processes all data locally in your browser.
Preset groupsSelect only the environments your repository actually uses.
Representative pathsOne repository-relative path per line, matched exactly as typed.

How to build and test a .gitignore file

Pick the preset groups your project needs and press Generate .gitignore. The eleven groups follow the usual ignore lists for Node.js, Python, PHP/Composer, Java/Gradle, Go, Rust, macOS, Windows, VS Code, JetBrains and local environment files; identical lines are written once and every group keeps its own comment and blank-line separation.

The paths panel is the tester. Type one repository-relative path per line and press Test paths: each line is matched against the generated patterns and the report answers ignored or included together with the pattern that decided it. Matching follows the gitignore(5) rules — a pattern that contains a slash is anchored to the repository root, * stops at a slash, ** crosses it, ? is one character, [abc] is a character class, a trailing slash means directory-only, and everything below an ignored directory stays ignored.

  1. Select the preset groups. Node.js, macOS, VS Code and Environment secrets start checked; untick whatever the repository does not use.
  2. Press Generate .gitignore. The output panel holds the merged file: one comment per group, duplicates removed, negations such as !.env.example kept and a trailing newline.
  3. Type test paths into the middle panel — one path per line, relative to the repository root, without a leading slash. Spaces are significant, exactly as in Git.
  4. Press Test paths. Every row reports ignored or included and the pattern that decided the verdict; the findings under the list name patterns Git treats differently.
  5. Copy the file or download it as .gitignore, or press Clear to start over. The presets live in the page script, so nothing is uploaded.

What the tester decides, and where it stops

How the presets are combined

Each group is a fixed list of lines. The generator writes the selected groups in the order of the checkboxes, skips a line that already appeared in an earlier group and keeps one blank line between groups. The negation lines shipped with the VS Code and environment groups are ordinary lines and stay exactly as written.

Nothing is fetched while generating: the preset lists come from the page script, so the same selection always produces the same text and the file can be built offline.

How a path is tested

The tester compiles every line of the generated file into a pattern and walks the path from the repository root downwards. A match on a parent directory decides the path before its own rules are read — that is why .vscode/settings.json stays ignored under the default selection even though the file also contains !.vscode/settings.json.

A path typed without a trailing slash is checked as a file and then as a directory, so a rule such as logs/ also covers a path written as logs. The report prints the pattern that decided each row, including negations.

What the findings mean

Two conditions are flagged for the generated file: a pattern ending in unescaped whitespace (Git trims it before matching) and a negation whose parent directory is excluded (Git never descends there, so the negation cannot re-include anything).

Every report ends with the same boundary: nested .gitignore files, core.excludesFile, case-insensitive file systems and the rest of the full Git engine are outside this test.

Recent tools: