gitignore Generator

About the gitignore Generator

Every repository needs a .gitignore, and almost nobody writes one from scratch. The usual approach is copying a file from a previous project, which carries rules for frameworks this project does not use and misses rules for the ones it does.

This assembles one from the stacks you actually tick. Node, Next.js, Python, Go, Rust, Java and Gradle, Android, Swift and Xcode, Unity, PHP, Ruby, Terraform, Docker, plus the operating-system droppings and editor directories that follow you between machines. Rules that appear in more than one block are written once, because the same pattern twice is a file a reader has to check for differences that are not there.

The secrets block is on by default, and it is the reason to use this rather than a copied file. Credentials reach public repositories through a small and stable set of filenames — .env and its variants, PEM keys, .p12 and keystore files, service-account JSON, an SSH private key committed by accident, an .npmrc carrying a registry token. Those patterns are collected in one block at the top with the exception for .env.example, which you do want tracked.

There is a limit worth understanding before you rely on any .gitignore, and the page repeats it under the result. Ignoring a file only prevents it from being added. A file already tracked continues to be tracked, and a file already committed stays in the history for good. If a secret has been committed, the fix is not a .gitignore entry: it is rotating the credential, because the old value is in every clone anybody made.

Add project-specific rules below the generated blocks rather than editing inside them, so regenerating the file later does not overwrite your own additions.

How to use it

1. 1Tick the stacks this repository actually uses. Two or three is usually the honest answer.
2. 2Leave the secrets block switched on unless you have a specific reason not to.
3. 3Choose whether to keep the section headings — they help whoever reads the file next.
4. 4Save the result as .gitignore in the repository root, and add your own rules underneath the generated blocks.

Questions

I added a file to .gitignore and Git still tracks it.

Ignoring applies only to untracked files. Once something is tracked, Git keeps tracking it. Run git rm --cached on the file to stop, then commit — that removes it going forward while leaving your local copy alone.

I committed a secret and then ignored it. Am I safe?

No. The value is in the repository history and in every clone and fork made since. Rotate the credential immediately. Rewriting history with git filter-repo or BFG helps, but only after the secret has been changed.

Should Cargo.lock or package-lock.json be ignored?

Lock files belong in version control for applications, so everyone builds the same dependency tree. For a published library, Cargo.lock is conventionally ignored because consumers resolve their own. The generated file notes this next to the Rust rules.

Where should my own rules go?

At the bottom, below the generated sections. That way regenerating the file when you add a stack does not overwrite anything you wrote, and a reader can see which rules were considered rather than assumed.