Introduction

To ignore a file only in the repository root, anchor the pattern in .gitignore with a leading slash. The slash tells Git to match from the root of the directory that contains that ignore file, not from every subdirectory. This is the difference between ignoring one specific root-level file and ignoring every file with the same name anywhere in the tree.

Root-Anchored Pattern

Suppose you want to ignore only the root-level config.env.

/config.env

With that rule:

• 'config.env in the repository root is ignored'
• 'src/config.env is not ignored'
• 'nested/folder/config.env is not ignored'

That leading slash is the key.

Compare It with an Unanchored Pattern

Without the slash, Git matches the filename in any directory.

config.env

That rule would ignore config.env everywhere in the repository. So if the requirement is "root only," the anchored form is the correct one.

Example Layout

Imagine this tree:

1repo/
2  .gitignore
3  config.env
4  app/
5    config.env

With this .gitignore:

/config.env

Git ignores only the top file. The one under app/ remains visible to Git.

Already Tracked Files Need an Extra Step

.gitignore affects untracked files. If the root file is already tracked, adding it to .gitignore does not automatically remove it from version control.

git rm --cached config.env

Then commit the change.

git commit -m "Stop tracking root config.env"

After that, the ignore rule prevents it from being re-added accidentally.

Negation Rules Can Refine Larger Patterns

Sometimes a broader ignore rule already exists and you need to carve around it. Git supports negation with !, but the rules can get subtle.

For example:

*.env
!/app/config.env

That ignores all .env files except the one under app/. The main point is that root anchoring and negation are separate tools. Use the simplest rule that expresses the intent clearly.

Where the Root Is Measured From

The leading slash is relative to the directory containing that .gitignore file. If the .gitignore is in the repository root, then /config.env means the repository root. If the .gitignore is inside a subdirectory, the same syntax is anchored to that subdirectory instead.

That detail matters when projects use multiple .gitignore files.

Test the Rule When in Doubt

Git can tell you which ignore rule matched a file.

git check-ignore -v config.env
git check-ignore -v app/config.env

This is the fastest way to debug ignore behavior when several patterns interact.

Root-Only Directories Use the Same Idea

The same anchoring rule works for directories too. If you want to ignore a directory only at the repository root, anchor it the same way.

/build/

That ignores the root build directory but does not automatically ignore src/build/. The pattern language is consistent, which makes it easier to reason about file and directory rules together.

Common Pitfalls

• Using config.env instead of /config.env and accidentally ignoring the file everywhere.
• Forgetting that .gitignore does not stop tracking a file that is already committed.
• Assuming the leading slash always means repository root even when the .gitignore file lives in a subdirectory.
• Creating complicated negation patterns when a single root-anchored rule would be clearer.
• Debugging by guesswork instead of using git check-ignore -v to see the actual matching rule.

Summary

• Use a leading slash in .gitignore to ignore a file only at the root level.
• '/filename is root-anchored, while filename matches anywhere.'
• If the file is already tracked, remove it from the index with git rm --cached.
• Remember that the anchor is relative to the directory containing the .gitignore file.
• Use git check-ignore -v when multiple ignore rules make behavior unclear.