.gitignore Generator

What .gitignore does (and doesn't do)

.gitignore tells Git which files and directories to skip when staging changes. Each line is a pattern; matching paths never get added to commits, never show up in git status, and never accidentally get pushed. The file lives at the repo root (and can be supplemented by additional .gitignore files in subdirectories that scope to that subtree only).

What it doesn't do: remove files already tracked. If you accidentally committed node_modules, adding it to .gitignore won't untrack it — you still need to run git rm -r --cached node_modules and commit the deletion. After that, the ignore rule prevents re-staging.

Pattern syntax — the things that confuse everyone

• Leading slash anchors to repo root. /build matches only ./build, not src/build. Without the slash, build matches anywhere.
• Trailing slash means directory only. logs/ matches the directory but not a file named logs. logs matches both.
• Double-star matches any depth. **/node_modules matches at any nesting level. logs/** matches everything inside the logs directory.
• Negation with ! re-includes. *.log followed by !important.log ignores all logs except that one. Order matters — the negation has to come after the pattern it overrides.
• Comments start with #. A literal hash at the start of a filename can be escaped: \#weird-file.
• Whitespace at end of line is included in the pattern unless escaped. logs (trailing space) does not match logs. Save with no trailing whitespace.

What should ALWAYS be in your .gitignore

• Secrets: .env, .env.local, credentials.json, *.pem, anything with API keys or passwords. Once a secret is committed, it's effectively leaked — git history is forever. Rotate the key, then update gitignore.
• Dependency directories: node_modules/, vendor/, .venv/, target/. These are reproducible from lockfiles — never commit them.
• Build artifacts: dist/, build/, *.exe, *.dll, compiled binaries. Generate on demand.
• OS metadata: .DS_Store (macOS), Thumbs.db (Windows), desktop.ini. Polluting collaborators' repos.
• IDE settings (most of the time): .vscode/, .idea/. Per-developer preferences shouldn't be shared. Exception: shared run configurations, project-wide debugger setups — those go in a separate committed file.
• Logs and runtime data: *.log, tmp/, cache/.

What should NOT be in your .gitignore

• Lock files. package-lock.json, yarn.lock, Gemfile.lock, poetry.lock should all be committed. They guarantee reproducible builds across machines. Ignoring them defeats the entire point of having lockfiles.
• Test snapshots. Jest's __snapshots__ and similar should be committed and reviewed in diffs.
• Editor configs that are project-scoped. .editorconfig at the repo root standardizes indentation across editors — commit it.
• CI configuration. .github/workflows/, .gitlab-ci.yml — these define what runs in CI. Always commit.

Global gitignore — for files Git should never see anywhere

Some files (your editor's swap files, system metadata) belong in a global gitignore that applies to every repo on your machine, not the per-project one. Set it up once:

git config --global core.excludesFile ~/.gitignore_global

# Then put things like this in ~/.gitignore_global:
.DS_Store
*.swp
.vscode/
.idea/

This way, projects you contribute to don't get cluttered with rules for your specific tooling — and you don't have to re-add the same OS/editor patterns to every new repo.