.gitignore Generator

Build a .gitignore by picking your stack: language(s), framework(s), IDE(s), OS. Templates are based on the curated github/gitignore repository. Combine as many as needed and de-duplicate the result.

How to use the .gitignore Generator

Select languages, frameworks, IDEs, and OS (hold Ctrl/Cmd for multi-select). Generate combines the templates and removes duplicate lines. Download for a ready-to-commit file at the repo root.

What .gitignore keeps out of your repo

Committing build output, dependency folders, editor settings, and OS junk is one of the most common ways a repository gets messy: node_modules balloons the clone size, .DS_Store files appear in every directory, and one person’s local IDE config overwrites everyone else’s. A .gitignore tells Git which paths to leave untracked so they never reach the repository in the first place.

This assembles one from curated templates for your languages, frameworks, IDEs, and operating systems, combining and de-duplicating them into a single file. It controls what Git ignores; for consistent editor behaviour across the team add an .editorconfig generator file, and to keep the same noise out of Docker build contexts generate a .dockerignore file.

Common use cases

  • New repo setup — start with the right ignores for your whole stack at once.
  • Multi-language projects — combine, say, Node and Python ignores without hand-merging.
  • Stop committing secrets — ignore .env and local config before they ever leak.
  • Cross-platform teams — exclude both macOS and Windows junk files in one file.
  • Cleaner history — keep build artifacts and caches out of version control.

Frequently asked questions

A file is already tracked — will adding it here ignore it?
No. .gitignore only affects untracked files; run git rm --cached on an already-committed file first, then commit.

Where do the templates come from?
They are based on the community-maintained github/gitignore collection, combined and de-duplicated here.

Should .gitignore itself be committed?
Yes — commit it at the repo root so every contributor shares the same rules.

What about Docker build contexts?
Use a separate .dockerignore; the .dockerignore generator builds one with the same idea.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: