.gitignore Builder

Select project types to generate a combined .gitignore. Add custom rules at the bottom.

Project Types
Custom Rules
Generated .gitignore
Select project types on the left to generate your .gitignore.

How to Use the .gitignore Builder

  1. Select your project types — check every language or framework used in your project. You can select multiple types and patterns will be combined without duplicates.
  2. Add custom rules — paste any extra patterns in the custom rules textarea. One pattern per line.
  3. Copy or download — click Copy to copy to clipboard, or Download to save as a ready-to-use .gitignore file.
  4. Place in your repo root — drop the file in the root of your Git repository (the same folder as your .git directory).

What Is a .gitignore File?

A .gitignore file is a plain text file that tells Git which files and directories to exclude from version control. When Git scans your project for changes, it skips any files that match patterns in .gitignore. This prevents large, auto-generated, or sensitive files from being accidentally committed to your repository.

Why .gitignore Matters

Without a proper .gitignore, several problems can occur. Developers may accidentally commit node_modules/, which contains thousands of files that can be reinstalled with a single command. Secrets like .env files containing API keys and database passwords may be exposed publicly on GitHub or GitLab. Build artifacts like dist/, target/, and __pycache__/ bloat repository size unnecessarily. OS-generated files like .DS_Store (macOS) and Thumbs.db (Windows) create meaningless noise in pull requests.

Pattern Syntax

  • node_modules/ — trailing slash means directory only
  • *.log — asterisk matches any string of characters
  • **/*.pyc — double asterisk matches across directory levels
  • /dist — leading slash anchors pattern to repo root
  • !important.log — exclamation mark negates (re-includes) a pattern
  • # comment — lines starting with # are ignored

Language-Specific Patterns

Node.js: The most important pattern is node_modules/. Always ignore this directory — it can contain hundreds of megabytes and is fully reproducible with npm install. Also ignore .env to protect environment variables, and dist/ or build/ for bundled output. Lock files (package-lock.json, yarn.lock) are a special case — these should usually be committed for applications but ignored for published libraries.

Python: Ignore __pycache__/ and *.pyc to exclude compiled bytecode files. Ignore .venv/ or venv/ for virtual environments, similar to how Node.js ignores node_modules/. The *.egg-info/ pattern excludes packaging metadata generated during development installs.

Java: Ignore target/ for Maven builds or build/ for Gradle builds. IDE-specific directories like .idea/ (IntelliJ), .eclipse/, and *.iml files should generally be excluded, though some teams prefer to commit shared IDE settings.

Rust: Ignore the /target/ directory, which contains compiled output and can be several gigabytes for large projects. The Cargo.lock rule is nuanced — commit it for binary applications (it ensures reproducible builds) but add it to .gitignore for library crates (it prevents downstream crates from being pinned to your versions).

Global vs. Project .gitignore

OS-specific patterns like .DS_Store (macOS Finder metadata) and Thumbs.db (Windows Explorer thumbnails) are better placed in a global .gitignore file at ~/.gitignore_global. Configure Git to use it with git config --global core.excludesfile ~/.gitignore_global. This keeps project .gitignore files focused on project-specific patterns and avoids polluting shared repositories with personal machine-specific entries.

Already Tracked Files

Adding a pattern to .gitignore does not automatically untrack files that Git is already following. If you accidentally committed a file before adding it to .gitignore, run git rm --cached filename (or git rm -r --cached directory/ for directories) to stop tracking it. The file remains on disk but will be excluded from future commits. Commit the removal separately so teammates get the untracking change.

Frequently Asked Questions

A .gitignore file tells Git which files and directories to exclude from version control. When you add a pattern to .gitignore, Git will stop tracking matching files. This is used to exclude build artifacts, dependencies (like node_modules), secrets (.env files), and OS-generated files (.DS_Store, Thumbs.db).
Create a file named exactly '.gitignore' (no extension) in your repository's root directory and paste your patterns. If you have already committed files that should be ignored, you need to remove them from tracking first using 'git rm --cached filename' before the .gitignore takes effect.
Yes. You can place a .gitignore file in any subdirectory. Patterns in a subdirectory .gitignore apply only to files in that directory and below. A global .gitignore file (~/.gitignore_global) applies to all repositories on your machine, which is useful for OS-specific files like .DS_Store.
If node_modules was already committed before you added it to .gitignore, Git will continue tracking it. Run 'git rm -r --cached node_modules' to remove it from tracking, then commit the change. After that, the .gitignore pattern will work for future files.
In .gitignore, lines starting with # are comments and are ignored by Git. Lines starting with ! (exclamation mark) are negation patterns that re-include files excluded by earlier patterns. For example, you can ignore all .log files with '*.log' and then re-include a specific log file with '!important.log'.