In a Git .gitignore file, what do a leading slash, a trailing slash, and ** match?

## What a pattern is matched against Each line of a `.gitignore` is a pattern in Git's own glob dialect, close to shell globbing but with its own anchoring rules. Patterns are evaluated relative to the directory containing the file, and they are applied to paths inside that directory tree only. ## Anchoring: the slash rule The single most misread rule is that the presence of a slash changes the match target. - **No slash at all** (`build`, `*.log`): the pattern is matched against the file or directory *name*, at any depth. `build` hides a top-level `build` and also `src/vendor/build`. - **A slash anywhere except the end** (`/build`, `doc/frotz`, `src/*.log`): the pattern becomes a full relative path pattern anchored at the directory of the `.gitignore`. `/build` hides only the top-level one; `doc/frotz` hides only that path, not `a/doc/frotz`. A leading slash is therefore just the cheapest way to say "this exact place, not everywhere". ## Trailing slash: directories only `logs/` matches a directory named `logs` and everything inside it, and never a regular file named `logs`. Dropping the slash makes the pattern match either kind. Directory-only patterns also have a performance consequence: once a directory is excluded, Git does not descend into it, which is why negations inside an excluded directory do not work. ## Wildcards `*` matches any run of characters *except* `/`; `?` matches exactly one character except `/`; bracket expressions like `[0-9]` and `[a-z]` work as in shell globs. `**` is the only construct that crosses separators, and it is meaningful in three positions: - **Leading** `**/foo` matches `foo` at any depth (the same as writing bare `foo`, but explicit). - **Trailing** `foo/**` matches everything inside `foo`, at any depth. - **Middle** `a/**/b` matches `b` directly under `a` and under any number of intermediate directories. ## Ordering: last match wins Git does not stop at the first hit. It applies every pattern in the file and the **last** one that matches decides the outcome. That is why a `!` negation must come after the rule it is undoing, and why appending a broad `*.log` at the bottom silently undoes carefully placed exceptions above it. ## Per-directory layering `.gitignore` files can sit in any directory. For a given path, Git reads the file in the path's own directory and every parent up to the top of the work tree, and files closer to the path win over files further away. A subdirectory can therefore relax or tighten what the root file said, which is how a `vendor/.gitignore` keeps its rules out of everyone else's way. ## Small syntax details that show up in interviews - A line starting with `#` is a comment; to ignore a file whose name really starts with `#`, escape it as `\#`. - Trailing whitespace is stripped unless escaped with a backslash, which is a real cause of "my pattern does nothing" reports. - A leading `!` means negation, so a filename genuinely starting with `!` must be written `\!important.txt`. - Blank lines match nothing and are conventionally used as separators. ## Verifying instead of guessing Rather than reasoning about a pattern in your head, ask Git: `git check-ignore -v <path>` prints the source file, line number and pattern responsible for excluding a path, and exits non-zero when nothing matches. That is the fastest way to settle an argument about anchoring.