Introduction

Git ignores subfolders through .gitignore pattern rules, but the exact pattern matters because Git distinguishes between paths anchored at the repository root and patterns that can match anywhere. The other important detail is that .gitignore only affects untracked files; if a folder is already tracked, ignoring it later is not enough by itself.

Ignore a Specific Subdirectory

If you want to ignore one known directory at the repository root, list it with a trailing slash:

build/

That ignores the build directory and everything inside it.

If the directory is nested:

src/generated/

This ignores that specific path from the repository root.

Ignore a Directory Name Anywhere

If you want to ignore any folder with a given name, no matter where it appears, use a double-star pattern:

**/logs/

This matches:

• 'logs/'
• 'api/logs/'
• 'services/auth/logs/'

That is useful when a project creates the same kind of transient directory in multiple places.

Ignore Only Certain File Types Inside Subfolders

Sometimes you do not want to ignore the folder itself, only files within matching subdirectories.

**/cache/*.tmp

This ignores temporary files in any cache subdirectory while leaving other files in the same directories visible to Git.

Re-Including a File

You can also unignore a specific file with !, but only if the parent directory is not fully blocked from traversal in a way that prevents Git from seeing the file.

logs/
!logs/keep-me.txt

In practice, unignore rules are easiest to reason about when you ignore file patterns rather than entire parent trees.

Already Tracked Files Are Different

This is the part that surprises many people. Suppose logs/ is already tracked. Adding it to .gitignore does not remove it from version control automatically.

You must stop tracking it explicitly:

git rm -r --cached logs
git commit -m "Stop tracking logs directory"

After that, the .gitignore rule prevents the folder from being added again accidentally.

Local-Only Ignores

If the ignore rule is just for your machine and should not be committed, use the repository's local exclude file:

.git/info/exclude

That is useful for editor folders, private scratch files, or machine-specific outputs that teammates should not inherit.

.gitignore Files Can Be Nested

You are not limited to one top-level .gitignore. Git can also read ignore rules inside subdirectories. That is useful when a particular subtree has its own local build outputs:

app/
  .gitignore
  tmp/

Inside app/.gitignore you might write:

tmp/

That rule is interpreted relative to the directory containing that .gitignore file.

Common Pitfalls

The most common mistake is adding a directory to .gitignore and expecting already tracked files to disappear. Ignore rules affect future tracking decisions, not files already in the index.

Another issue is misunderstanding rooted versus non-rooted patterns. build/ in the repository root is different from **/build/ if you intend to match directories at every depth.

A third pitfall is overusing broad patterns and accidentally hiding files that matter. Patterns like **/tmp/ are powerful, so be sure they reflect the real project layout.

Finally, .gitignore is not a security mechanism. Ignoring a directory does not protect secrets that were already committed or shared.

Summary

• Use .gitignore patterns to ignore subdirectories at specific paths or at any depth.
• A trailing slash means you are targeting a directory.
• Use **/name/ when the directory name can appear anywhere in the repository.
• Ignore rules do not remove files that are already tracked.
• Use .git/info/exclude for machine-local ignore rules that should not be committed.