Gitignore Generator

What is a .gitignore file?

A .gitignore file tells Git which paths to leave out of version control. It lives at the root of your repository and is itself committed — so every clone applies the same rules. Without one, you end up tracking compiled binaries, dependency folders, IDE caches, log files, and (worst of all) secrets like .env files. Once those land in history they can stay searchable forever, even after a force-push, which is why getting .gitignore right at project start matters more than people think. This generator merges battle-tested patterns for the languages, frameworks, operating systems, and editors you actually use, then deduplicates the headers so the file stays readable. It only outputs path patterns — never source code — so it is safe to drop straight into a public repo. If your project mixes a backend, a frontend, two operating systems, and three editors across the team, just tick all of them: the result is a single file, not a folder, and Git treats every line as additive. You can paste it as a starting point and tweak from there.

How to use it

1. Pick your templates

Click any chip from the language, OS, or editor lists. Use the filter box at the top if the list is long — it matches both the label and the internal key.

2. Review the output

Each template gets its own commented section header (# === Node.js ===) so you can tell at a glance which rules came from where. Order is the order you clicked.

3. Copy or download

Copy the whole thing to your clipboard, or hit Download to save it directly as .gitignore. Drop it at the root of your repo before your first commit.

4. Tweak as needed

Treat the output as a starting point. Add project-specific paths (uploads, generated docs, scratch files) at the bottom, and remove any rule that does not apply to your setup.

What each rule does

Patterns in .gitignore follow simple rules. A literal path like node_modules/ ignores that directory anywhere it appears. A leading slash (/dist) anchors the pattern to the repo root. Glob characters work as expected: *.log matches files by extension, **/cache recurses, and brackets like *.[oa] match a character set. A leading ! negates a previous rule, which is how Unity keeps .meta files even when their target is ignored. Lines starting with # are comments. Trailing slashes mean “directory only”. Already-tracked files are not affected — to remove a file from tracking after adding it to .gitignore, run git rm --cached path.

When to add what

Pick language and framework templates for build artefacts and dependency folders (node_modules/, vendor/, target/). Add the OS template for the systems your team uses — macOS leaves .DS_Store everywhere and Windows scatters Thumbs.db. Add an editor template for whatever IDE the team standardises on; if people use a mix, add all of them. As a rule of thumb: at least one stack + one OS + one editor for any new repo. Avoid ignoring lockfiles (package-lock.json, composer.lock, Gemfile.lock) — those should be committed for reproducible builds.

Frequently asked questions