gitignore Generator — Build a .gitignore From Your Stack
Tick the languages, frameworks, editors and operating systems your project actually involves and get a single tidy .gitignore back, with rules that appear in more than one template written only once. Copy it, or download it straight as a .gitignore file. The whole thing runs in the page — no request, no account, no rate limit.
Nobody writes a .gitignore from memory, and the cost of getting it wrong is asymmetric. Miss node_modules and every clone drags tens of thousands of files; miss .env and you have published a set of credentials that will still be in the history after you delete the file. The rules below are grouped the way people actually think about a project — what it is written in, what it is built with, what they edit it in, and what operating system is dropping files into the directory.
Ignoring is not the same as removing
A .gitignore only affects files Git has not started tracking. Adding a line for a file that is already committed does nothing at all — the file keeps being tracked, and every change to it keeps showing up. To stop tracking something without deleting it from your disk, run git rm --cached <file> and commit that. And if what leaked was a secret, removing it from the current commit is not enough: the old value remains in history and has to be treated as compromised, which means rotating the key, not just deleting the line.
Negation, order, and the one rule that catches people out
Patterns are applied in order, and a later rule beats an earlier one — which is how .vscode/* followed by !.vscode/settings.json hides a whole folder except for the one file the team shares. The exception is that you cannot un-ignore a file inside a directory that is itself ignored: Git never looks inside it, so the negation is never reached. Ignore the contents rather than the folder when you need that, which is why the editor templates here use .vscode/* and not .vscode/.
Where the file should live
A .gitignore in the repository root covers everything below it and is what belongs in version control. Rules that are personal to you — your own editor, your scratch directory — belong in .git/info/exclude instead, which is local and never committed, or in a global ignore file configured with git config --global core.excludesFile. Keeping personal preferences out of the shared file is the difference between a .gitignore that stays short and one that accumulates a decade of other people’s tooling.
Related: check a permission string with the chmod calculator, test a pattern in the regex tester, or compare two configs in the diff checker.
How to use gitignore Generator
- Search or scroll to find what your project uses — the language, the framework, your editor, and the operating systems on your team.
- Tick everything that applies. Choices from different groups combine, so Node plus Next.js plus VS Code plus macOS is a normal selection.
- Read the generated file. Each block is labelled, and a rule shared by two templates is written once under the first one.
- Copy it into an existing .gitignore, or download it as a ready-made file for the repository root.
- If anything you just ignored is already committed, run git rm --cached on it — the ignore rule alone will not stop it being tracked.
Features
- Thirty-four templates — languages, frameworks, editors, operating systems and tooling, grouped so they are easy to find.
- Duplicates merged — build/ and node_modules/ appear once even when four of your selections ask for them.
- Labelled sections — every block says which template it came from, so the file stays maintainable.
- A secrets template — .env files, keys and certificates, with example files deliberately un-ignored.
- Editor templates that share what should be shared — .vscode settings and launch configs stay in the repo while the rest is ignored.
- Runs locally — no API call, no rate limit, and it works offline once the page has loaded.
Frequently Asked Questions
I added a rule but Git still tracks the file. Why?
Because .gitignore only applies to untracked files. Once a file is committed, Git keeps tracking it regardless. Run git rm --cached path/to/file and commit the removal, and the ignore rule takes effect from then on.
I committed a .env file. Is ignoring it now enough?
No. Deleting and ignoring it removes it from the current commit, but the old contents are still in the repository history and in every clone. Treat the credentials as compromised and rotate them — that is the only fix that actually works.
Why is it .vscode/* and not .vscode/?
Because you cannot un-ignore something inside an ignored directory — Git does not descend into it, so the negation is never evaluated. Ignoring the contents instead lets the following lines keep settings.json, launch.json and extensions.json in the repository.
Where should the file go?
In the repository root, committed, so everyone on the project shares it. Anything personal to your machine belongs in .git/info/exclude or in a global ignore file set with git config --global core.excludesFile.
Can I have more than one .gitignore?
Yes. A .gitignore in a subdirectory applies to that directory and everything under it, and its rules are evaluated after the root file. It is a reasonable way to keep rules for a sub-project next to the sub-project.
Should I ignore lock files like package-lock.json?
No — commit them. Lock files are what make an install reproducible for everyone on the team and in CI. None of the templates here ignore them.
How do I check whether a particular file is ignored?
Run git check-ignore -v path/to/file. It prints the exact file and line number of the rule that matched, which is the fastest way to work out why something is or is not being tracked.