Protect Files That Shouldn't Be Committed with .gitignore

What you'll walk away with

Understand protecting files with .gitignore without the fear factor
Get hands-on and try it yourself
Learn to spot (and smile past) the common mistakes

Create a .gitignore that keeps node_modules, build output, local environment files, and editor clutter out of your Git commits.

Let's think about it this way for a sec

.gitignore is a list of rules telling Git 'don't track these file patterns.' Folders you can reinstall, like node_modules, output you can rebuild, like .next or dist, and files that might contain secrets, like .env.local, shouldn't be committed to the repository. Lockfiles, though, should be committed so you get exact dependency versions back. But having a .gitignore alone doesn't make your secrets safe — a new ignore rule can't retroactively untrack a file Git is already tracking.

Connecting it to everyday life

Create a .gitignore in the project root and add patterns that match your stack. For .env.example, you can commit it with just the key names and fake or blank values. Check git status again to confirm node_modules, .next, dist, and .env.local no longer show up. If a secret has ever been committed, deleting the file isn't enough — you need to revoke/rotate the key.

Dependencies and build output are ignored
.env and local secret files are ignored
The lockfile is not ignored
No real secret values are in .env.example

Let's try it together

text

# Dependencies
node_modules/

# Build output
.next/
dist/
coverage/

# Local environment files
.env
.env.local
.env.*.local

# Editor / operating system
.vscode/
.DS_Store
Thumbs.db

You should see

You'll have a .gitignore that fits your project, and secrets, dependencies, and generated output will no longer end up in your commits.

5-Minute Try-It

Adapt the sample .gitignore to your own stack. Then check git status again to confirm files that should be ignored no longer appear.

A Quick Word of Caution

Never treat AI output as automatically correct. Have a human read through the code and test it — and double-check secrets and user data — before you rely on it.

Easy traps

Ignoring package-lock.json or pnpm-lock.yaml along with node_modules
Putting a real API key into .env.example
Thinking a secret that's already been committed is safe just because you added it to .gitignore

Now Try It Yourself

Adapt the sample .gitignore to your own stack. Then check git status again to confirm files that should be ignored no longer appear.

You'll know it worked when: You'll have a .gitignore that fits your project, and secrets, dependencies, and generated output will no longer end up in your commits.