A .gitignore for your stack, without the copy-paste archaeology
Every repository needs a .gitignore, and every repository gets one by copying the nearest example, which is how projects end up ignoring files they needed or missing files they did not. This builds one from what you actually use.
- Stacks
- 16
- Groups
- Editor, OS, secrets
- Output
- Ready to paste
How to use it
- Pick your stack Node, Python, Go, Rust, Java, Ruby, PHP, .NET, Elixir, Swift, Kotlin, Terraform, Docker and more. You can select several.
- Add the standard groups Operating system files, editor and IDE directories, local environment files and build output. Most of them are wanted by everybody.
- Copy the file The result is a complete, commented .gitignore, ready to paste into the root of a repository.
Reference
The sections you get
| Section | What it covers |
|---|---|
| Operating system | `.DS_Store`, `Thumbs.db`, `.Spotlight-V100` |
| Editors | `.vscode/`, `.idea/`, `*.swp` |
| Environment | `.env`, `.env.local`, `*.pem` |
| Dependencies | `node_modules/`, `vendor/`, `.venv/` |
| Build output | `dist/`, `build/`, `target/` |
| Logs and caches | `*.log`, `.cache/`, `__pycache__/` |
Questions people ask
I already committed a secret. Is the .gitignore enough?
No. Ignoring a file does not remove it from the history. Remove it from the index, rewrite the history if it matters, and rotate the credential — a secret that was pushed should be considered compromised.
Should I ignore lock files?
No. Lock files should be committed, because they are what makes an install reproducible.
Why does it ignore .env?
Because environment files usually contain credentials and the local ones are machine-specific. Commit a .env.example with the keys and no values instead.
Can I add my own patterns?
Yes, and you should. The generated file is a starting point; put your project-specific exceptions at the bottom, where the ordering makes them win.
Does it include secrets?
It includes the common secret file names — .env, *.pem, *.key, credentials files — which is the behaviour most people want.
Is the file uploaded?
No. It is assembled in your browser and copied as text.
Where this earns its keep
Starting a new repository
A correct .gitignore from the first commit is much easier than adding one later, because a file that was already committed stays in the history.
Stopping a build artefact from being committed
A specific pattern added to the .gitignore stops the next commit, and the tool tells you the file is still tracked so you can untrack it.
Reviewing somebody else's repository
Checking what a repository ignores tells you what it is expected to build and which files are considered local.
Details that catch people out
A .gitignore only affects files that are not already tracked. If a secret was committed, adding it to the .gitignore changes nothing and the secret stays in the history. It has to be removed from the index and, if it was a real credential, rotated.
Later patterns override earlier ones, so a broad rule followed by a narrow exception behaves the way you expect. The generated file groups the rules so exceptions are easy to add at the bottom.
A .gitignore is usually copied from a stranger
The most common .gitignore on GitHub is enormous, includes patterns for a hundred languages nobody in the project uses, and occasionally ignores something the project needs. A generated one contains what your stack actually produces.
- Only the stacks you select, plus the universal groups.
- Commented, grouped and ordered so it stays readable.
- A reminder that ignoring a file is not the same as untracking it.
- Built in the browser, no account, nothing stored.
Last reviewed 2026-10-16. Every tool on DevSnap runs entirely in your browser, so whatever you paste here never reaches a server.