MMakerToLaunch

Guides

What Is a .gitignore File?

A .gitignore file tells Git which files to skip when tracking and uploading your project. It is one of the simplest, highest-impact files in your repo — and one AI tools sometimes forget to configure correctly. One well-placed .gitignore line can prevent API keys, multi-gigabyte dependency folders, and local databases from reaching GitHub.

Updated July 2026 · 6 min read

Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.

Quick answer

.gitignore is a text file in your project root listing patterns (like .env and node_modules/) that Git should never commit. It keeps secrets and generated folders off GitHub while your actual source code uploads normally.

Who this is for

  • You are about to upload an AI-built project and want to avoid leaking .env
  • GitHub Desktop shows thousands of files including node_modules
  • You added .env to .gitignore but it still appears in commits

What you'll need

  • Your project root folder (where package.json or manage.py lives)
  • A text editor or your AI coding tool
  • Five minutes before your first Git commit

A simple definition

.gitignore is a plain text file named exactly .gitignore (leading dot, no extension) in your repository root. Each line is a pattern. Git compares every file in your project against those patterns and excludes matches from staging and commits.

Ignored files stay on your computer. They simply never upload to GitHub. Your teammates clone the repo without your local .env — they create their own from .env.example.

Gitignore is not encryption and not a security product by itself. It prevents accidental commits. If you already pushed a secret, you must rotate the key and remove it from history — ignoring going forward is not enough.

Why it matters at launch

Launch paths start with GitHub. The most common catastrophic mistake for AI-built apps is uploading a .env file containing OpenAI, Stripe, or database credentials. .gitignore is the first line of defense.

The second common mistake is uploading node_modules/ or .venv/ — folders that can contain tens of thousands of files and hundreds of megabytes. Hosts rebuild dependencies from package.json or requirements.txt; you do not need to upload them.

A launch readiness scan checks for missing or weak .gitignore patterns. Fixing ignore rules before the first push is far easier than cleaning Git history afterward.

A beginner example

Lovable exports a React app. Your folder contains .env with VITE_SUPABASE_URL and a secret key, plus node_modules/ from npm install.

You create .gitignore in the project root with these lines: .env, .env.local, node_modules/, dist/. You save the file.

In GitHub Desktop, node_modules and .env disappear from the changed-files list. Only source code and config remain. You commit and publish safely.

You add .env.example with the same variable names and placeholder values. Collaborators and your host know what to configure without seeing real secrets.

Essential patterns for AI-built apps

Start with this baseline and add stack-specific lines:

  • .env, .env.local, .env.*.local — secret configuration
  • node_modules/ — JavaScript dependencies (reinstall with npm install)
  • .next/, dist/, build/, out/ — frontend build output
  • .venv/, venv/, __pycache__/ — Python environments and cache
  • *.pyc, .pytest_cache/ — Python bytecode and test cache
  • db.sqlite3, *.db — local SQLite databases
  • .DS_Store, Thumbs.db — OS junk files
  • *.pem, *.key, credentials.json — certificates and cloud keys
  • .idea/, .vscode/ (optional) — editor settings (some teams commit shared settings)

How to create and verify .gitignore

Create a new file named .gitignore in your project root — same level as package.json or manage.py. Add one pattern per line. Lines starting with # are comments.

Use our GitHub safe-upload tool or ask your AI tool to generate a .gitignore for your stack (Next.js, Django, Rails, etc.). Framework templates exist at github.com/github/gitignore.

Before committing, run git status or check GitHub Desktop's file list. If .env or node_modules still appear, your pattern is wrong or the file was tracked before you ignored it.

Commit .gitignore early — ideally in your very first commit — so secrets never enter history.

If a file was uploaded before ignoring

Adding a pattern to .gitignore does not remove files already committed. Git keeps tracking them until you explicitly remove them from the index.

If .env was committed: rotate every key immediately, run git rm --cached .env (or remove via GitHub Desktop by deleting the file from the repo while keeping the local copy), commit, and push. Consider history cleanup tools if keys were public.

If node_modules was committed: add node_modules/ to .gitignore, remove from Git tracking, commit. Future clones will npm install instead.

When in doubt after a secret exposure, rotate keys first — that limits damage even while you clean history.

.gitignore vs empty folders

Git does not track empty folders. If your app needs an empty uploads/ directory structure, teams sometimes add uploads/.gitkeep — a tiny placeholder file — while ignoring uploads/* except .gitkeep.

This is an edge case for first launch. Focus on .env and node_modules first; refine folder rules when your app actually needs them.

Common mistakes

  • No .gitignore at all before first push

    How to fix it: Create one before any commit. Use stack templates or the safe-upload tool.

  • Ignoring .env.example

    How to fix it: .env.example should be committed — only real .env files stay ignored. Pattern .env ignores all .env* unless you negate with !.env.example.

  • Assuming .gitignore removes secrets already on GitHub

    How to fix it: Rotate keys and remove files from Git history. Ignore rules only affect future commits.

  • Wrong .gitignore location

    How to fix it: Place it in the repository root. Nested .gitignore files work for monorepos but beginners should start at root.

  • Committing .env because it was tracked before .gitignore

    How to fix it: Untrack with git rm --cached, commit removal, rotate secrets if they were ever pushed.

Copy-ready prompt

Prompt: audit my .gitignore

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready to paste

Audit my project's .gitignore before I upload to GitHub.

1. Read my current .gitignore (or create one if missing).
2. Identify my stack (Next.js, Django, etc.) and list required ignore patterns.
3. Confirm .env and dependency folders (node_modules, .venv) are covered.
4. Check if any sensitive files are currently tracked by Git despite ignore rules.
5. Suggest updates and explain each pattern in plain language.
6. Verify .env.example exists and is NOT ignored.

Do not commit or display real secret values.

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready check

Beginner checklist

  • .gitignore exists in project root
  • .env and .env.local are listed
  • node_modules/ or .venv/ is listed for your stack
  • Build output folders (.next, dist, build) are listed
  • Local database files (db.sqlite3) are listed if applicable
  • .env.example is committed with placeholder values
  • Git status shows no .env or node_modules before first push

Frequently asked questions

Does .gitignore work on GitHub Desktop?
Yes. .gitignore is a standard Git feature — Desktop, VS Code, Cursor, and terminal Git all respect it.
Can I have multiple .gitignore files?
Yes in monorepos with subfolders. Beginners should use one root .gitignore unless you know you need nested rules.
Why is .env still showing after I added it to .gitignore?
The file was probably already tracked. Remove it from Git with git rm --cached .env, then commit.
Should I ignore package-lock.json or yarn.lock?
Usually no — lock files should be committed so installs are reproducible on your host.
What is the difference between .gitignore and .env?
.env holds secrets locally. .gitignore tells Git not to upload .env. They work together.

Related reading