Ignoring Files

A .gitignore file tells Git which untracked paths to never offer for staging — build output, dependency directories, secrets, and editor cruft. It keeps the noise out of git status so the files that matter are visible.

The higher-stakes job is keeping things out of history entirely. Without an ignore rule it is far too easy to git add . a .env file full of credentials, and once a secret is committed, ignoring it afterward does nothing — it is already in history for anyone with a clone to read. Getting the ignore rules right before the first commit is cheaper than the cleanup later.

How Matching Works

Patterns are globs. A bare name like build matches that name anywhere in the tree; a leading / anchors it to the directory the .gitignore sits in. * matches within one path segment, ** spans directories, a trailing / restricts the match to directories, and a leading ! negates an earlier rule to re-include something. The anchoring detail matters: node_modules unanchored can match a file of that name buried somewhere unexpected, while /node_modules/ targets exactly the top-level directory you meant.

Where Ignore Rules Live

Rules come from several places. A .gitignore in any directory applies to that directory and below, the root file holds the project-wide rules everyone shares, and the per-machine core.excludesFile holds rules that are about your setup, not the project. The distinction is editorial: project artifacts like dist/ belong in the committed file; your editor's .idea/ and macOS .DS_Store belong in your personal global excludes, not forced onto every collaborator.

Already-Tracked Files

.gitignore only governs untracked files. Adding a rule for a file Git already tracks changes nothing — Git keeps tracking it and keeps committing your edits. To stop tracking it while leaving it on disk, run git rm --cached <path>, which removes it from the index so the next commit drops it, and only then does the ignore rule take effect. Editing .gitignore alone cannot do this.

What to Ignore and What Not To

Ignore generated and reconstructible things: dependency directories like node_modules/, build output like dist/, and any .env holding secrets. Do not ignore lockfiles — package-lock.json, yarn.lock, poetry.lock pin exact dependency versions, and ignoring them makes builds non-reproducible across machines because everyone resolves slightly different versions.

Debugging Ignore Rules

When a file is ignored that should not be, or vice versa, stop guessing which of the layered files is responsible. git check-ignore -v <path> prints the exact file, line number, and pattern that matched. It is the fastest way to settle why git status is or is not showing something.