gitignore generator

Skip the files Git shouldn't track

A good .gitignore keeps the noise out of your repository — build output, dependency folders like node_modules, virtual environments, editor settings and OS junk like .DS_Store. Forgetting it is how huge dependency folders and machine-specific files end up committed by accident. Select the technologies your project uses and this tool assembles a sensible starting .gitignore from well-established defaults.

Combine as many as you need

Real projects span several environments — a Node app edited in VS Code on a Mac, say — so tick every option that applies and the relevant rules are merged into one file with clear section headings. Drop it in your project root as .gitignore and commit it. You can always tweak it afterwards; this gives you a solid base instead of a blank page.

It only applies to untracked files

This is the single biggest source of confusion with .gitignore: it stops Git picking up files it is not already tracking. Adding a rule for a file that has been committed does nothing — Git keeps tracking it, and your changes keep showing up.

To stop tracking something already in the repository, remove it from the index while leaving it on disk: git rm --cached path/to/file, or git rm -r --cached node_modules for a folder. Commit that, and the ignore rule takes over from then on. Note that the file stays in your history; if it was a secret, rotate the credential, because deleting it from the current commit does not remove it from earlier ones. The Git commands cheat sheet covers the related plumbing.

Pattern syntax worth knowing

• build/ — a trailing slash matches directories only, never a file of the same name.
• *.log — a wildcard within one path segment; it will not cross a /.
• **/temp — a double asterisk does cross directory boundaries, matching temp at any depth.
• !important.log — a leading ! negates an earlier rule and re-includes the file.
• /config.json — a leading slash anchors the pattern to the repository root rather than matching at any level.

Order matters, because the last matching rule wins. One catch defeats people regularly: you cannot re-include a file with ! if one of its parent directories is itself ignored, because Git never descends into an excluded directory to discover it. Unignore the directory first, then exclude its contents.

Where the rules can live

A .gitignore in the repository root covers the whole project and is what you commit and share. You can also place one inside a subdirectory, where it applies from that point down — handy when a single folder has unusual output.

For patterns that are about you rather than the project — your editor's scratch files, a personal notes file — use .git/info/exclude, which behaves identically but is never committed. Teammates on different editors will thank you for keeping those out of the shared file.