Introduction

Some paths should be ignored on every clone — dependencies, build output, secrets. Others are local only: draft docs, scratch scripts, a specs folder beside the code. Both stay out of git status, but they do not belong in the same ignore file.

.gitignore is committed and shared; every pattern you add is a tracked change on the remote. .git/info/exclude lives inside .git/ on your machine, uses the same syntax, and is never committed. Matched files disappear from git status the same way — the ignore rule itself never shows up in a PR.

`.gitignore` vs `.git/info/exclude`

Same pattern syntax. Same effect on untracked files. Different scope for the rule.

	`.gitignore`	`.git/info/exclude`
Tracked in git	Yes	No
Shared with collaborators	Yes	No
Shows up in PRs when you add a pattern	Yes	No
Good for project-wide rules	Yes	No
Good for personal/local-only paths	No	Yes
Survives `git clone` on a new machine	Yes	No — recreate manually

Use .gitignore for team-wide rules (node_modules, .env, .next/). Use exclude for paths only your clone should ignore — a local specs folder (e.g. /requirements/), drafts, helper scripts, or OS-specific paths.

The trade-off with exclude: teammates do not inherit your rules, a fresh clone will not restore them, and already-committed files stay tracked until you run git rm --cached.

Where Git reads ignore rules

Git merges patterns from three sources:

Mechanism	Location	Committed?	Scope
`.gitignore`	Repo root (or nested)	Yes	Everyone who clones
`.git/info/exclude`	Inside `.git/`	No	Current clone only
Global exclude	`core.excludesfile`	No	All repos on the machine

Project rules go in .gitignore. Clone-local rules go in exclude. A global exclude file applies personal patterns across every repo without touching tracked project files.

Setup

This walkthrough ignores a local requirements/ folder — files stay on disk, but git stops listing them. Run everything from the repo root.

Step 1 — see the problem. If a folder is not ignored yet, git treats it as untracked and keeps reminding you to commit it:

That folder is useful locally, but you do not want it in the repo. The usual fix is adding a line to .gitignore, which creates a commit. exclude avoids that.

Step 2 — add the pattern. Open .git/info/exclude in your editor, or append from the terminal. The leading / means "only at the repo root," same as in .gitignore:

>> appends to the file. The \n before the pattern starts it on a new line so it does not run into the previous entry.

Step 3 — confirm git sees the rule. check-ignore tells you which file, line, and pattern matched — useful when a path is still showing up:

If this prints nothing, the pattern does not match. Check spelling, slashes, and whether the file was already tracked.

Step 4 — confirm git status is clean. Run git status again. requirements/ should be gone from the untracked list. The folder and its files are still on disk; git simply stops reporting them.

Step 5 — confirm the remote is untouched. Because you edited .git/info/exclude instead of .gitignore, there is nothing to commit:

No output. Your ignore rule never leaves this machine.

On a new clone or a new laptop, recreate the same lines in .git/info/exclude — git does not copy them for you.

Caveats

Ignore rules only affect untracked files. Committed by mistake? Run git rm --cached <path> first.

Some tools read .gitignore from the repo but not .git/info/exclude. You may need tool-specific config if a linter or IDE still picks up a locally ignored folder.

Conclusion

.gitignore is for project rules — shared and versioned. .git/info/exclude is for local rules — private and unversioned. Same syntax, different scope. When you want ignore behavior without a commit, use exclude.

How to Keep Local Files Out of Git Without Touching `.gitignore`

How to Keep Local Files Out of Git Without Touching `.gitignore`

Comments