.gitignore Generator

About .gitignore Generator

A .gitignore file tells Git which untracked files to pretend it cannot see: build output, dependency folders, files the operating system drops everywhere, and environment files holding secrets. It has no effect on files Git already tracks, which is the source of most confusion about it.

This generator combines templates for languages, frameworks, operating systems and editors into one file. Whatever order you click them in, the output is always sorted language, then framework, then OS, each block headed by a comment such as ### Node.js ###, and anything you type as extra patterns goes last under ### Custom ###. Most templates are based on GitHub's github/gitignore collection.

Four pattern rules people get wrong

Straight from the Git documentation:

• A trailing slash means directories only. build/ ignores a directory named build and everything in it, but not a file named build.
• A slash at the start or in the middle anchors the pattern to the location of the .gitignore file. /TODO matches only the top-level TODO, and doc/frotz matches only doc/frotz relative to that file. A pattern with no slash, like *.log or node_modules/, matches at any depth.
• ** spans directories. **/logs matches logs anywhere; a/**/b matches a/b, a/x/b and a/x/y/b.
• Within one file, the last matching line wins. Negations with ! therefore have to come after the rule they override.

When a ! negation silently does nothing

The documentation is explicit: it is not possible to re-include a file if a parent directory of that file is excluded. For performance reasons Git does not even list the contents of an excluded directory, so a negation for a file inside it is never evaluated.

The VS Code template in this tool is written around exactly that rule. It uses .vscode/* rather than .vscode/, then re-includes !.vscode/settings.json, !.vscode/extensions.json and a few others. .vscode/* excludes the directory's contents, not the directory, so Git still looks inside and can apply the exceptions. Written as .vscode/, every exception below it would be dead. The Node.js template's .env.* followed by !.env.example works the same way: .env.local with real keys stays out, while the example file documenting required variables is committed.

Adding a file to .gitignore does not untrack it

Ignore rules only apply to untracked files. Once a file has been committed, Git keeps tracking changes to it no matter what .gitignore says. To stop, remove it from the index only with git rm --cached path (git rm -r --cached dir for a folder) and commit. The file on disk is left alone.

Secrets need more than that. If you committed a .env file and then untracked it, the contents are still in every earlier commit, and if you pushed, anyone who cloned has them. Rotate the credentials first; rewriting history is a secondary cleanup.

Lines to check before using a template as-is

Templates are written broadly for the common case, and a broad rule can hide real source code. This tool's Python template includes lib/, build/ and dist/; if your project has its own lib package, new files there will quietly never be committed. The Node.js template ignores out and dist, and the JetBrains template ignores out/ as well.

To see why a file is ignored, run git check-ignore -v path. It prints the .gitignore file, line number and pattern responsible. If a template catches a folder you need, add a negation such as !lib/ in the extra patterns box; because extra patterns are appended at the very end, they override the template rules above them.

Editor and OS files (.DS_Store, Thumbs.db, .idea/) can also go in a personal global ignore file set with git config --global core.excludesFile. In a shared repository you cannot count on every contributor having done that, so listing them in the project's .gitignore is the safer default.

Worked examples

How to use it

1. Search for or pick your languages, frameworks, OS and editors.
2. Add any extra paths, or ! exceptions to undo a template rule, in the extra patterns box.
3. Save the result as .gitignore in the repository root and check git status to confirm the right files disappeared.

Frequently asked questions