.gitignore Generator
Pick your languages, OS, and editor to assemble a best-practice .gitignore from built-in templates — no more committing node_modules.
Check the boxes for your stack — Node, Python, Java, Go, macOS, Windows, VS Code, and more — and get a single combined .gitignore with labeled sections. Templates follow community best-practice patterns. Copy the result into your repo root and commit it.
# Generated with the CodeToolWorks .gitignore Generator # --- Node.js --- # dependencies node_modules/ # logs npm-debug.log* yarn-debug.log* yarn-error.log* *.log # environment .env .env.local # build output dist/ build/ # misc coverage/ .DS_Store
How to use this calculator
- Check the boxes for every language, OS, and editor in your stack.
- Click Generate to assemble the combined .gitignore with labeled sections.
- Review the output, then click Copy .gitignore.
- Save it as .gitignore in your repository root.
- Run ‘git status’ to confirm the ignored files disappear from tracking.
Worked example
Selecting Node and Python produces a file headed ‘# Generated with the CodeToolWorks .gitignore Generator’, with a Node.js section containing node_modules/ and a Python section containing __pycache__/ — 413 characters covering both ecosystems.
Frequently Asked Questions
What should never be committed to a repository?
Three categories: secrets (API keys, .env files, credentials), generated artifacts (node_modules, build output, compiled binaries), and machine-specific files (OS metadata like .DS_Store, editor settings). Secrets are the critical one — once pushed, a key must be considered compromised and rotated. Dependencies and build output bloat the repo and are reproducible from lockfiles and source.
Does the order of rules in a .gitignore matter?
Yes. Git applies patterns top to bottom, and the last matching pattern decides. This lets you write broad ignores and then carve out exceptions with negation: ‘*.log’ followed by ‘!important.log’ ignores all logs except important.log. It is also why this generator groups templates into labeled sections — related rules stay together where you can reason about their order.
A file is in .gitignore but still shows up — why?
.gitignore only prevents untracked files from being added; it does not untrack files Git already knows about. If the file was committed before the rule existed, remove it from the index with ‘git rm --cached <file>’ — this stops tracking it without deleting your local copy. Then commit the removal, and the ignore rule will keep it out going forward.
Should OS and editor files go in the repo .gitignore?
For personal projects it is harmless, but the cleaner practice is a global .gitignore for machine-specific files. Run ‘git config --global core.excludesFile ~/.gitignore_global’ and put .DS_Store, Thumbs.db, and .vscode/ there. That keeps every repo’s .gitignore focused on the project itself, and you never have to think about OS files again. This generator includes them as checkboxes so solo developers get a complete file in one step.
Why do the templates ignore .env files?
Because .env files conventionally hold secrets: database passwords, API keys, and signing tokens. Committing them publishes those secrets to everyone with repo access — and if the repo is public, to the entire internet, where scanners harvest keys within minutes. Commit a .env.example with placeholder values instead, so teammates know what variables the project needs without exposing the real ones.