.gitignore Generator

The Kordu .gitignore Generator produces ready-to-commit .gitignore files by combining curated templates for the languages, frameworks, IDEs, and operating systems in your project. Pick any combination of 17 templates and the sections are merged, labelled, and de-duplicated into a single copy-ready file. Defaults to Node.js + VS Code + macOS — the most common web developer stack — but every template is opt-in so you end up with patterns that match your actual repository and nothing you don't need.

What .gitignore does and why it matters

A .gitignore file lives at the root of your repository (or inside any subdirectory) and tells Git which paths to leave untracked. Compiled output, dependency trees, IDE metadata, OS junk files, build caches, virtual environments, and secrets should never enter version control — they bloat the repo, leak environment-specific state across machines, trigger noisy diffs, and in the worst case commit credentials to a public history. A well-written .gitignore is the single most effective way to keep your repository clean, portable, and safe.

Anatomy of a gitignore rule

Each non-empty, non-comment line in .gitignore is a pattern. Patterns follow shell glob syntax with a few Git-specific extras:

• *.log — match any file ending in .log in any directory
• build/ — trailing slash means match directories only
• /secrets.json — leading slash anchors the pattern to the repo root
• **/node_modules — the double-star globs across any depth
• docs/**/*.pdf — recursive match inside docs/
• !important.log — a leading ! negates a previous ignore, re-including the file
• # comment — lines starting with # are ignored (use \# to match a literal #)
• Blank lines are allowed and help readability; they have no effect.

Order matters for negation: a !pattern only works if none of its parent directories are ignored. If you ignore logs/ you cannot re-include logs/keep.log — you must ignore logs/* instead and then negate the file.

How the 17 templates compose

Select any combination of templates and the generator merges them into one file with a labelled header per section (# Node.js, # Python, # macOS and so on). Duplicate patterns that appear in more than one template are emitted once, and the output is sorted by section so diffs stay stable when you add or drop a stack later. The templates cover:

• Language runtimes — Node.js (node_modules/, npm-debug.log*, .pnpm-store/), Python (__pycache__/, *.py[cod], .venv/, *.egg-info/), Go (vendor/ optional, *.exe, *.test, coverage profiles), Rust (target/, Cargo.lock for libraries, **/*.rs.bk), Java (*.class, target/, build/, *.jar).
• Frontend and backend frameworks — React (build/, .eslintcache), Next.js (.next/, out/, .vercel), Vite (dist/, dist-ssr/, .vite/), Laravel (/vendor, /node_modules, storage/*.key, .env), Django (*.sqlite3, media/, staticfiles/, local_settings.py).
• Editors and IDEs — VS Code (.vscode/* minus shared settings.json, extensions.json, launch.json), JetBrains (.idea/, *.iml, out/).
• Operating systems — macOS (.DS_Store, ._*, .AppleDouble, .Spotlight-V100), Windows (Thumbs.db, ehthumbs.db, Desktop.ini, $RECYCLE.BIN/), Linux (*~, .Trash-*, .nfs*).
• Infrastructure tools — Docker (*.pid, .docker/), Terraform (.terraform/, *.tfstate, *.tfstate.backup, .terraform.lock.hcl kept committed).

Framework-specific gotchas worth knowing

Next.js produces .next/ for dev builds and out/ for next export — both need to be ignored. Vite writes to dist/, not build/, so a stale React template alone will miss it. Create React App uses build/. Django developers often forget to ignore local_settings.py and *.sqlite3, leaking developer databases into history. Laravel ships with its own .gitignore in new projects; if you are migrating an older repo, make sure /storage/*.key, /bootstrap/cache/, and .env are all listed. Rust library crates should ignore Cargo.lock; binary crates should commit it so release builds reproduce.

OS traps that pollute every repo

macOS writes .DS_Store into every directory a Finder window has ever opened, and they sneak into commits the moment a teammate browses src/ in a GUI. Windows drops Thumbs.db, ehthumbs.db, and Desktop.ini in folders with images; Linux produces editor backups like *~ and NFS lock files like .nfs0001. Add all three OS templates even when your team is uniformly on one platform — CI agents, contractors, and future maintainers may not be. A shared repo gets OS junk from every contributor, not just you.

IDE noise and the shared-settings split

JetBrains (.idea/) and VS Code (.vscode/) are both user-specific by default, but VS Code projects frequently want to commit shared settings: settings.json, extensions.json, and launch.json ensure everyone has the same formatter, recommended extensions, and debug configurations. The generated VS Code template ignores the folder but re-includes those three files via negation patterns. Delete the negations if your team prefers a strictly private .vscode/ directory, or extend them if you standardize tasks.json too.

Secrets and credentials: ignore first, audit always

Any file that could leak a credential belongs in .gitignore before you even write the secret. Always ignore .env, .env.local, .env.*.local, *.pem, *.key, id_rsa*, credentials.json, service-account*.json, and .npmrc if it contains auth tokens. Keep .env.example (note the .example suffix) committed so teammates know which variables the app needs — documenting shape without leaking values is the whole point. If a secret ever lands in history, rotating it is the only real fix: git rm leaves the leaked value in prior commits, and force-pushing over a public history is not a containment strategy.

Lock files: generally commit, don't ignore

package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb, Pipfile.lock, poetry.lock, Gemfile.lock, Cargo.lock (for binaries), and composer.lock all pin exact dependency versions. Commit them so CI, teammates, and production all install the same tree. None of the built-in templates ignore them, and you should not add them manually unless you have a very specific reason.

The most common .gitignore mistake: forgetting already-tracked files

.gitignore only prevents Git from starting to track new files — it does nothing to files already under version control. If node_modules/ made it into your repo before you added the ignore rule, a fresh rule will not clean it up. Run git rm -r --cached node_modules to untrack everything under that path while leaving the files on disk, commit the deletion, then future clones will not pull those files and the ignore rule will start working. The same applies to .DS_Store, compiled artifacts, and any secret that slipped in — untrack, commit, then rotate the secret.

Testing and debugging your rules

git check-ignore -v path/to/file tells you exactly which line in which .gitignore matched (or didn't). git status --ignored lists files the rules are currently hiding. Use them whenever a pattern surprises you — especially when debugging negation and deep globs, which have notoriously non-obvious semantics.

Global vs per-repo vs .git/info/exclude

Three levels of ignore exist, each with its own scope:

• Per-repo .gitignore (checked in) — shared with the team; this is what the generator produces.
• Global ~/.gitignore_global — configured via git config --global core.excludesfile ~/.gitignore_global. Ideal for personal editor and OS patterns you don't want to impose on teammates.
• .git/info/exclude — per-clone, never shared, never committed. Useful for one-off local scratch files.

A common pattern is: keep the OS and IDE templates in your global ignore, and keep only language and framework patterns in the per-repo file. That keeps team repos focused on the project itself.

Comparison to toptal/gitignore.io and github/gitignore

The canonical community sources are GitHub's github/gitignore repository and the toptal/gitignore.io service. Both ship hundreds of templates and are excellent for obscure stacks. The Kordu generator targets the 17 templates that cover >90% of modern web, mobile, and infrastructure projects, merges them with a sharper UI, and ships zero dependencies — no API calls, no external service, no signup. Your selections never leave the browser.

Privacy and data processing

All template composition and de-duplication happens entirely in your browser. Kordu does not upload, log, or store your selections or the generated output. The tool is pure client-side JavaScript: no backend, no rate limits, no signup, and it works offline once the page has loaded.