.gitignore Pattern Coverage Checker
Check whether .gitignore rules cover generated and sensitive repository paths, with gate metrics for negations, tracked files, gaps, and review actions.| {{ header }} | Copy |
|---|---|
| {{ cell.value }} {{ displayCell(cell) }} | |
| No rows for the current input. |
A useful .gitignore file is a shared repository boundary, not a catch-all cleanup list. It tells Git which intentionally untracked paths should stay out of commits, usually because they are generated by tools, restored from package managers, created by an editor, or tied to one developer's machine.
That boundary matters most when repository noise can hide a real code change or when local files carry private values. Build output, dependency caches, coverage reports, test snapshots, local environment files, certificates, and operating-system files can all look harmless until they inflate reviews, break another developer's checkout, or leave sensitive material in history.
Ignore rules only apply to paths Git still sees as intentionally untracked. Once a file has been added to the index, a later ignore pattern will not make future changes disappear; the path has to be removed from tracking first. That distinction is easy to miss when a team adds patterns such as .env*, coverage/, or dist/ after those files have already been committed.
Shared ignore rules also sit beside other exclude sources. A repository .gitignore travels with clones and documents project-wide intent. A local exclude file or global exclude file can hide personal editor, backup, or operating-system clutter, but those private rules do not prove that a teammate or build system will get the same protection.
Coverage review asks whether the shared patterns match the generated or sensitive path classes that actually occur in a repository sample. A useful review needs both sides: rules that express intent and a path inventory that shows what is present in the working tree, status output, diff output, or build artifacts.
- Pattern
- A line in an ignore file, such as
node_modules/,*.pem, or!dist/README.md. - Candidate path
- A repository path that deserves review because its name or location suggests generated output, local configuration, reports, or sensitive material.
- Winning rule
- The last matching rule that decides whether the path is ignored or re-included.
- Negation
- A
!rule that can make a previously ignored path visible again, but only when parent directory rules allow Git to reach it.
| Path class | Typical examples | Why coverage matters |
|---|---|---|
| Generated output | dist/, build/, target/, compiled assets |
Regenerated files can create large noisy diffs and stale artifacts. |
| Dependency caches | node_modules/, package caches, vendor downloads |
Restored dependencies belong in package metadata or lock files, not ordinary commits. |
| Local configuration | .env, .env.local, machine-specific settings |
Values can differ per developer and may include credentials or private endpoints. |
| Reports and editor files | coverage/, .DS_Store, temporary files |
They can distract from source changes and reveal local tooling habits. |
Common failures come from rules that look correct in isolation but fail in combination. Later matches can override earlier matches, negation can re-include generated files, and re-include rules cannot recover a child path when its parent directory remains excluded. Coverage also changes when a path list omits a generated folder or when case sensitivity assumptions differ from the repository configuration.
For repositories that handle secrets, generated reports, project templates, or multi-language build output, ignore coverage is a review clue rather than a security guarantee. It can reveal missing patterns and tracked cleanup work, but it cannot prove a repository has no secrets or that every developer's local exclude rules match the shared rules.
How to Use This Tool:
Start with the shared ignore rules and a path sample from the same repository state. The result is only as good as those two inputs.
- Use Repository to label the review when the exported report needs to identify a project, branch, template, or cleanup pass.
- Set Coverage target to the minimum acceptable share of selected candidate paths that should be ignored.
- Edit Generated or sensitive terms so the candidate set matches your repository. Terms may be plain path segments or globs such as
node_modules/,dist/,coverage/,.env*,*.pem, and.DS_Store. - Paste or browse .gitignore rules. Use the rules that should protect shared repository content, then use Normalize if pasted whitespace or line endings need cleanup.
- Paste or browse Repository paths. The input can be a plain path list,
git status --shortoutput, or name-status style path output from a diff. - Open Advanced only when the review should use case-insensitive matching. Default Git ignore matching is case-sensitive, so leave the default unless the repository is being audited under a different assumption.
- Resolve any Review input messages before trusting the gate. Missing terms, missing usable rules, invalid patterns, or an empty path inventory make the percentage misleading.
Use Coverage Gate Metrics for the pass-or-review decision, Path Ignore Ledger for per-path action, Pattern Audit Queue for rule behavior, and Ignore Coverage by Path Class to see where uncovered, tracked, or blocked paths cluster.
Interpreting Results:
The coverage percent answers one narrow question: among the paths selected by the generated or sensitive terms, how many are ignored by the final matching rule? It does not cover files absent from the pasted inventory, and it does not prove the repository contains no secrets.
A clear gate requires more than meeting the percentage target. The selected candidate set must be non-empty, the coverage percentage must meet the target, every selected path must be ignored, no ignored candidate may appear tracked, no negation may be blocked by an ignored parent directory, and every parsed rule must be valid.
| Ledger outcome | Meaning | What to check next |
|---|---|---|
| covered | The candidate path is ignored by the final winning rule. | Confirm the candidate term itself is appropriate for the repository. |
| uncovered | No current rule ignores the candidate path. | Add or adjust a focused ignore rule before relying on the coverage target. |
| tracked cleanup | The path matches an ignore rule but appears already tracked. | Remove the path from the index after confirming it should stay out of history. |
| blocked negation | A re-include rule is defeated because an earlier parent directory rule prevents Git from reaching the child path. | Re-include the parent directory path before relying on the child exception. |
| re-included | A negation rule makes a selected candidate visible again. | Confirm the exception is intentional, especially for secrets, reports, or build output. |
The chart is useful after the ledger has rows because it groups review work by path class. A single uncovered secret or configuration path can matter more than a large number of harmless generated files, so use the chart to focus cleanup rather than to replace the per-path ledger.
Technical Details:
Git ignore evaluation is a pattern walk, not a simple string search. Git can read ignore patterns from command-line options, nested ignore files, the repository's local exclude file, and a user-level global exclude file. Within one precedence level, the later matching pattern decides the outcome, so rule order is part of the meaning.
Repository-level review usually focuses on the rules that should be shared with everyone who clones the project. Those rules need to match the generated and sensitive paths that can appear in normal development: dependency caches, build output, local configuration, coverage reports, private certificates, and editor or operating-system files. A coverage percentage is therefore a sampled audit of shared intent, not a complete scan of every ignore source Git can consult.
Pattern syntax has several traps. Blank lines are only separators, unescaped # begins a comment, trailing spaces are ignored unless escaped, and a trailing backslash leaves a pattern invalid. A leading ! changes a match from ignore to re-include, but that exception still cannot expose a child path when its parent directory has already been excluded.
Formula Core
Coverage is the share of selected generated or sensitive candidate paths ignored by the final rule state.
If 38 generated or sensitive paths are selected and 36 are ignored, coverage is 94.7 percent after one-decimal display rounding. A 95 percent target still queues review, and the gate also queues review when any selected path is uncovered, tracked, blocked by negation, or affected by an invalid rule.
Rule Core
| Pattern feature | Behavior | Review risk |
|---|---|---|
| Last match wins | Rules are evaluated in order, and the later matching rule controls the final ignored state. | A later broad rule can undo an earlier exception, or a later negation can re-include a risky path. |
| Anchoring | A slash at the beginning or middle makes the pattern relative to the ignore file's directory level; a pattern without a slash can match below that level. | A rule that looks root-only may match more locations than intended when it has no slash. |
| Negation | A leading ! re-includes a path that was previously ignored. |
It cannot re-include a child if the parent directory remains ignored. |
| Directory pattern | A trailing slash matches directories and paths below them, not ordinary files with the same name. | A file named like a directory pattern may remain uncovered. |
| Tracked path | A path already in the index is still tracked even when an ignore rule matches it. | Index cleanup is needed before the ignore rule prevents future commits. |
| Double-star glob | ** can match across directory levels in supported positions. |
Small pattern changes can widen or narrow coverage significantly. |
Input and Classification Core
| Input shape | How it is read | Why it matters |
|---|---|---|
| Plain path list | Each usable line is treated as a repository path with an unknown Git state. | Good for exported inventories, but it cannot distinguish tracked cleanup from ordinary coverage. |
git status --short style lines |
Status prefixes such as ??, M, and A are used to infer untracked or tracked state. |
Tracked generated files can be flagged separately from paths that only need ignore-rule coverage. |
| Name-status output | Tab-separated or status-prefixed path exports are normalized to the final path when possible. | Rename and copy lines can still contribute the destination path to the coverage review. |
| Selector terms | Terms select candidate paths by segment, prefix, or glob-style match depending on the term. | The coverage denominator changes when the term list is too broad, too narrow, or missing a generated path class. |
| Case mode | Case-sensitive matching follows the normal Git assumption; case-insensitive mode is an audit override. | Changing this option can move paths into or out of the candidate set and alter rule matches. |
Output Evidence Core
| Result area | Main evidence | Use |
|---|---|---|
| Coverage Gate Metrics | Coverage gate, candidate count, ignored candidates, tracked generated paths, negation exceptions, active rules, and case mode. | Decide whether the sample passes the target or needs cleanup. |
| Path Ignore Ledger | Path, path class, Git state, ignore outcome, winning rule, and recommended action. | Fix uncovered, tracked, and blocked paths one by one. |
| Pattern Audit Queue | Rule line, pattern, behavior, status, match counts, and review note. | Find inactive, invalid, broad, or risky negation rules. |
| Ignore Coverage by Path Class | Covered, uncovered, tracked cleanup, and blocked negation counts by class. | See whether uncovered paths cluster around secrets, coverage, dependencies, reports, or operating-system clutter. |
Limitations and Privacy Notes:
The checker evaluates the rules and paths you paste in the browser. It does not inspect the repository directly, read credentials, combine every ignore source Git can use, or prove that no secrets exist elsewhere.
- Repository-level rules, nested ignore files, local excludes, and global excludes may differ from the pasted rules.
- Coverage depends on the path inventory; missing generated or sensitive paths cannot be flagged.
- Tracked cleanup requires a Git index action such as removing the path from tracking after confirming it should remain untracked.
- For final diagnosis in a real checkout, compare the sampled result with Git's own ignore checks.
Worked Examples:
Template cleanup before first commit
A new web project has rules for node_modules/, dist/, and .env*, and the pasted path list includes ?? node_modules/vue/index.js, ?? dist/app.js, and ?? .env.local. With matching generated or sensitive terms and a 95 percent target, Coverage Gate Metrics can show the gate as clear because all three selected candidates are ignored.
Near miss against a strict target
A larger repository sample selects 38 candidate paths and 36 are ignored by the final winning rules. The displayed coverage is 94.7 percent, so a 95 percent target remains in review. Path Ignore Ledger should identify the two uncovered paths, while Ignore Coverage by Path Class shows whether they belong to build output, coverage reports, dependencies, secrets, or editor clutter.
Tracked report that still needs cleanup
A status line such as M coverage/lcov.info can appear as tracked cleanup even when coverage/ is present. The ignore rule matches, but Git already knows about the file, so the recommended action points to index cleanup after confirming the report should remain untracked.
Exception blocked by its parent directory
A ruleset with logs/ followed by !logs/keep.log can produce blocked negation for ?? logs/keep.log. The parent directory is still excluded, so the child exception cannot take effect until the parent path is re-included correctly.
If Generated or sensitive terms is empty, no candidate paths can be selected. Fix the term list first, then use Path Ignore Ledger so the percentage is based on the repository paths that actually matter.
FAQ:
Why is an ignored file still showing as tracked?
Ignore rules apply to intentionally untracked files. If a generated path is already in the index, Path Ignore Ledger marks it as tracked cleanup so you can remove it from tracking after confirming it should stay untracked.
Can negation always re-include a file?
No. A negation rule cannot re-include a child path when an ignored parent directory prevents Git from listing the child. Fix the parent directory rules first.
What path inventory should I paste?
Paste a representative list of repository paths, git status --short output, or name-status diff output that includes generated and sensitive candidates. The coverage percent only covers paths present in that input.
Should matching be case-sensitive?
Default Git ignore matching is case-sensitive. Use the case-insensitive audit mode only when your repository and platform behavior make that the review assumption.
Why is the coverage percent zero?
The candidate set is probably empty. Add generated or sensitive terms that match the pasted paths, or paste a path inventory that includes the generated files you want to review.
Why did a pattern show as inactive?
The pattern did not match any pasted path. That may mean the rule is obsolete, the path inventory is incomplete, or the rule protects a path class not present in this sample.
Glossary:
- Candidate path
- A pasted repository path selected by the generated or sensitive terms.
- Winning rule
- The last matching valid rule that decides the final ignored state for a path.
- Negation
- A
!pattern that re-includes a path previously ignored by another rule. - Tracked cleanup
- A path that matches an ignore rule but appears already tracked by Git.
- Blocked negation
- A re-include attempt that cannot work because a parent directory remains ignored.
References:
- gitignore Documentation, Git, 2026-04-20.
- git-check-ignore Documentation, Git, 2025-11-17.
- git-rm Documentation, Git, 2025-06-16.
- Ignoring files, GitHub Docs.