Skip to content
ZeroServer.tools

.gitignore Generator

Generate a .gitignore file by selecting your tech stack — Node, Python, Go, Rust, and more.

Tech stacks
·
.gitignore

What belongs in a .gitignore file?

A .gitignore tells Git which files and directories not to track — typically compiled output (dist/, target/), dependency folders (node_modules/), environment files (.env), and OS artefacts (.DS_Store, Thumbs.db). Patterns support glob syntax: leading ! negates a rule, trailing / matches directories only, and ** matches any depth. Combine entries from multiple stacks — for a Next.js project on macOS you want both the Next and macOS sections. To format your code before committing, visit the JSON Formatter or YAML Formatter.

Built and maintained by Meet Shah · Last updated

What this tool is used for

  • Producing a gitignore for a stack rather than writing one from memory.
  • Combining several stacks' patterns into one file.
  • Adding editor and OS patterns you always forget.
  • Producing a starting file you then extend per project.
  • Comparing a generated file against an inherited one.

Frequently Asked Questions

Why does gitignore not work on an already-tracked file?
Because it only affects UNtracked files. Once a file is in the index, git keeps tracking it regardless — `git rm --cached <file>` removes it from tracking while leaving it on disk, and that is the step people miss when a secret is committed.
How do the pattern rules work?
A leading slash anchors to the directory containing the file; a trailing slash matches directories only; `**` crosses directories; and `!` negates. The subtlety is that a negation cannot re-include a file if its parent directory is excluded — git never descends into it.
Where can .gitignore files live?
Any directory, with rules applying to that subtree and deeper ones overriding shallower. There is also a global ignore file for editor and OS artefacts, which is where `.DS_Store` and `.idea/` belong rather than in every repository.
Does ignoring a file remove it from history?
No. History is immutable, so a committed secret stays in every clone until the history is rewritten with `filter-repo` or BFG — and even then, the correct first response is to rotate the credential, because it must be assumed compromised.
What is usually forgotten?
Environment files, editor directories, OS metadata, build output, and coverage reports. `.env` is the one that matters — a generated ignore file is worth checking against what your framework actually produces, since defaults lag behind tooling.

Common errors and gotchas

  • Adding a pattern for a file that is already tracked, which git keeps tracking until you remove it from the index.
  • Ignoring a lock file, which usually should be committed.
  • Ignoring a whole directory when one file inside it needs tracking, which needs a negation pattern.
  • Committing an ignore rule that hides a build output someone else needs.
  • Assuming ignoring a secret file protects it, when it may already be in the history.

Related Developer Utilities tools

Private & free — this tool runs entirely in your browser.

IndieKitShip your Next.js startup in days.affiliate