gitignore Generator

Curated rather than mirrored

The canonical collection of gitignore templates runs to hundreds of files and well over a megabyte, and nobody has ever needed most of it. What people need is a dozen stacks, three editors and the two operating systems that scatter metadata into every repository they touch.

So each template here is trimmed to the entries that earn their line, and each carries a one-line note - because half of these are genuine decisions rather than obvious ones. Whether a vendor directory belongs in the repository, whether the editor folder should be committed, and which build wrapper files must survive are all choices, and the defaults here have reasons.

• The Gradle and Maven wrappers are explicitly kept - excluding them breaks the build for everyone else
• The environment template ignores every dotenv variant while keeping the example file, which should be committed
• The Terraform template excludes state files, which hold secrets in plaintext
• The Android template excludes keystores while keeping the debug one

De-duplication that respects negations

Picking two overlapping templates should not emit the same pattern twice, so repeats are dropped and counted. Negations are the exception and are never treated as duplicates.

That distinction is load-bearing. Git applies the last matching rule, so a negation only works where it sits relative to the pattern it negates - collapsing or reordering those would silently change what is ignored, which is precisely how a wrapper jar goes missing from a repository.

Machine files versus project files

Editor and operating-system entries are grouped separately because they are not properties of your project at all. A colleague on another platform should not have to carry your platform’s metadata patterns, and there is a good argument that those belong in a global gitignore configured once per machine rather than in a file committed to every repository.

The tool offers them anyway, because most teams do commit them, and says which is which.

What it will not do

It cannot know your project. A generated file is a starting point that covers the usual build output for a stack, not an audit of what your repository is currently tracking.

It also does not untrack anything. Git ignores untracked files only, so a pattern added after a file has been committed changes nothing until you remove it from the index - and if that file was a credential, it remains in the history and must be treated as compromised regardless of what the gitignore says.