Every new Git repository needs a correctly configured .gitignore file, but writing one from scratch means remembering dozens of file patterns across every tool in your stack. This guide walks through generating one correctly, whether by hand or using a generator.
What You Need
- A new or existing Git repository
- Knowledge of which languages, frameworks, editors, and operating systems your project uses
- A text editor to create the file
The .gitignore Generator automates the steps below — check the relevant boxes for your stack and get a complete file instantly.
Step 1: Identify Your Project's Languages and Frameworks
List every language and framework your project uses — for example, Node.js for a backend, React for a frontend, or Python for a data pipeline. Each typically has its own set of files that shouldn't be committed: node_modules/ for Node.js, __pycache__/ for Python, *.class for Java, and so on.
Step 2: Identify Your Operating System
If your team works across different operating systems, include patterns for each — macOS generates .DS_Store files, Windows generates Thumbs.db and desktop.ini, and Linux generates various hidden cache files. Including all relevant OS patterns prevents any team member's OS clutter from appearing in commits.
Step 3: Identify Your Editors
Add patterns for whichever code editors your team uses. VS Code creates a .vscode/ folder for workspace settings, while IntelliJ and other JetBrains IDEs create a .idea/ folder. If your team uses multiple editors, include patterns for all of them.
Step 4: Always Include Environment File Patterns
Regardless of language or stack, always include .env and its variants (.env.local, .env.*.local) in your .gitignore. These files commonly contain API keys, database credentials, and other secrets that should never be committed to version control, public or private.
Example combined .gitignore for a Node.js + macOS + VS Code project:
# Node.js / npm
node_modules/
npm-debug.log*
dist/
# macOS
.DS_Store
# VS Code
.vscode/*
!.vscode/extensions.json
# Environment files
.env
.env.local
.env.*.local
Step 5: Add Any Project-Specific Patterns
Beyond the standard templates, add patterns specific to your own project — perhaps a local database file, generated documentation, or test output folders unique to how your project is structured.
Step 6: Save and Commit the File
Save the combined content as a file named exactly .gitignore in your repository's root directory, then commit it — ideally as one of the very first commits in a new repository, before any files matching your ignore patterns get accidentally committed.
Step 7: Untrack Any Already-Committed Files
If files matching your new patterns were already committed before you added .gitignore, adding the pattern alone won't remove them from tracking. Run:
git rm --cached -r node_modules
git commit -m "Untrack node_modules"
This removes the files from Git's tracking (without deleting them from your local filesystem) while respecting the new .gitignore going forward.
Common Mistakes to Avoid
Adding .gitignore after files are already committed. Set it up as early as possible in a new repository to avoid needing the untrack step later.
Forgetting environment files. This is the single most damaging omission, since it risks leaking real credentials into your Git history.
Copying an old project's .gitignore wholesale. Different projects need different patterns; review and adapt rather than blindly reusing.
Not committing the .gitignore file itself. The .gitignore file should be committed and shared with your team — it's not meant to be a personal, local-only file.
Key Terms
- .gitignore — a file listing patterns of files and folders Git should exclude from version control.
- Untracking — removing a file from Git's tracking using
git rm --cached, without deleting it from the local filesystem. - Open Source License — another standard project file, often set up alongside .gitignore when starting a new repository.