Loading the interactive tool… It runs in your browser — if it doesn't appear, enable JavaScript.
Pick your stack and get a .gitignore assembled from the patterns that matter, grouped and commented. Covers the common languages, frameworks, editors and operating systems, and you can combine as many as you need.
The secrets block is included by default and is the part worth caring about most. A committed `.env` file or private key stays in git history even after you delete the file, and the only real remedy at that point is rotating the credential — the ignore rule you add afterwards does nothing about what's already in the repo.
Frequently asked questions
Why isn't .gitignore working for a file I just added to it?
Because .gitignore only affects untracked files. If git is already tracking the file, the ignore rule is irrelevant — run `git rm --cached <file>` to stop tracking it while leaving it on disk, then commit. This is the single most common .gitignore confusion.
I committed a secret. Is adding it to .gitignore enough?
No. The value is in your git history and in every clone and fork, and rewriting history doesn't reach copies other people already have. Treat the credential as compromised and rotate it. Add the ignore rule as well, so it doesn't happen again.
Should I commit lock files?
For applications, yes — a lock file is what makes builds reproducible. For libraries, the convention is usually not to, since consumers resolve their own dependency tree. This generator ignores Cargo.lock under the Rust template on that basis; delete that line if you're building a binary rather than a crate.
How do I ignore everything except one file?
Ignore the pattern, then negate the exception: `.env` followed by `!.env.example`. Order matters — the negation must come after the rule it overrides. Note that you can't un-ignore a file inside an ignored directory; you have to ignore the directory's contents rather than the directory itself.