Gitignore Patterns: What to Ignore and Why

Many devs adopt the git add . (yolo, just yeet it all into the commit) workflow. It is fast, simple, and usually correct. But eventually you’ll have files in your repo directory that should never be committed: secrets, generated artifacts, dependency folders, and random local junk. That’s what .gitignore is for.

All the content from our Boot.dev courses are available for free here on the blog. This one is the “Gitignore” chapter of Learn Git. If you want to try the far more immersive version of the course, do check it out!

What Does .gitignore Actually Do?

A .gitignore file tells Git which untracked paths to ignore. For example this file:

node_modules
.env

Tells Git to ignore any untracked node_modules directories and .env files. If you run git status, those paths won’t show up as untracked. If you run git add ., those paths won’t be staged.

Where Should .gitignore Live?

Usually at repo root, but it doesn’t have to.

You can have multiple .gitignore files in subdirectories. A nested .gitignore applies to the folder it’s in and everything below it. So yes, this is valid:

repo/
  .gitignore
  src/
    assets/
      .gitignore

Nested ignore files are handy in monorepos or projects where one subtree has different artifact types.

Which .gitignore Patterns Matter Most?

The bread-and-butter patterns:

• *.txt wildcard matching
• /main.py rooted matching (anchored to the .gitignore location)
• !important.txt negation (unignore)
• # comment inline documation that doesn’t affect gitignore behavior

Order matters. Later rules can override earlier ones. For example:

temp/*
!temp/instructions.md

Everything in temp/ is ignored except instructions.md. The ! syntax is a negation pattern that can be used to reinclude specific files or directories that would otherwise be ignored by a previous pattern.

What Should You Ignore in Real Projects?

Good default categories:

1. Generated files (build outputs or transpiled files like dist/, build/, *.class, or a compiled executable)
2. Dependencies (like node_modules, venv, or package caches)
3. Personal/editor-specific files (like .DS_Store, *.swp, .vscode/, or IDE project files)
4. Sensitive files (like .env, secrets, tokens, credentials)

If a file can be recreated from source, or could leak secrets, it probably belongs in .gitignore.

Why Is Git Still Tracking a File After I Ignore It?

One confusing thing to many new developers is that .gitignore doesn’t untrack files that are already committed.

If you previously committed a file, adding it to .gitignore won’t magically remove it from history or tracking. You need to untrack it:

git rm --cached advert.html

Then commit that change. From then on, the ignore rule takes effect for that path.

Is There a “Perfect” .gitignore?

Not really. It depends on your stack and workflow.

Start with common rules, keep it small, and evolve it as the project evolves. Ignore aggressively for generated/sensitive junk, but don’t ignore source files your team actually needs.

Personally, I don’t like starting projects with massive templated .gitignore files because they can contain a lot of entries that aren’t specific to my code. I tend to add ignore rules as I go, which keeps the .gitignore focused on the actual needs of the project. It also stops me from being surprised later when something I thought would be tracked is getting ignored by a pre-populated template.