.gitignore Generator

How to Use

1. Search or browse templates by category — Languages, Frameworks, IDEs, OS, and Tools.
2. Select every template that applies to your project by clicking the checkbox next to each name.
3. Review selected templates in the pills section. Click the × to remove any you don't need.
4. Preview the combined .gitignore output below. Duplicate patterns across templates are automatically removed.
5. Click Copy to copy the contents to your clipboard, or Download .gitignore to save the file directly.

What Is a .gitignore File?

Every Git repository can include a special file called .gitignore that tells Git which files and directories to exclude from version control. Without it, Git would track everything in your project directory — including generated build artifacts, dependency folders with thousands of files, IDE configuration, OS metadata, and potentially sensitive files like .env containing API keys and passwords.

A well-crafted .gitignore keeps your repository clean, reduces clone and fetch times, avoids merge conflicts on generated files, and prevents accidental exposure of secrets. It's one of the first files you should create in any new project.

Pattern Syntax

Gitignore patterns use a simplified glob syntax. Here are the most important rules:

• * — matches any characters except a forward slash (/)
• ** — matches directories at any depth (e.g., **/logs matches logs, src/logs, a/b/logs)
• ? — matches exactly one character
• [abc] — matches any single character in the brackets
• dir/ — a trailing slash means "only match directories"
• /file — a leading slash anchors the pattern to the repository root
• !pattern — negates a previous ignore rule, re-including the matched files
• # — lines starting with # are comments

For example, *.log ignores all log files everywhere, while /debug.log ignores only debug.log in the root directory. The pattern build/ ignores any directory named build, and doc/**/*.pdf ignores all PDF files under the doc/ directory at any depth.

Global vs. Local .gitignore

Git supports three levels of ignore rules:

• Repository .gitignore — the standard .gitignore file at the project root (and optionally in subdirectories). Committed to the repo and shared with all collaborators.
• Global .gitignore — a personal file (typically ~/.gitignore_global) that applies to every repository on your machine. Set it up with git config --global core.excludesfile ~/.gitignore_global. Ideal for OS files (.DS_Store, Thumbs.db) and IDE files (.idea/, .vscode/) that are specific to your setup.
• .git/info/exclude — a per-repository exclude file that isn't committed. Useful for personal ignores that shouldn't affect other developers.

Best practice: put OS and IDE patterns in your global gitignore, and language/framework-specific patterns in the project's .gitignore. That way your teammates aren't forced to adopt your editor's ignore rules, and you don't clutter every project with the same OS-specific entries.

Common Mistakes

The most frequent .gitignore mistakes developers encounter:

• Adding .gitignore after files are already tracked — Gitignore only prevents untracked files from being added. If a file is already committed, adding it to .gitignore won't remove it. Run git rm --cached <file> first.
• Forgetting to ignore .env files — Environment files containing API keys, database passwords, and secrets should always be in .gitignore. Commit a .env.example file instead with placeholder values.
• Ignoring lock files incorrectly — Files like package-lock.json, yarn.lock, and Gemfile.lock should generally be committed (they ensure reproducible builds). Only Cargo.lock is typically ignored for library crates.
• Using overly broad patterns — A pattern like *.json could accidentally ignore configuration files you need tracked. Be specific: coverage/*.json is safer than *.json.
• Not testing patterns — Use git check-ignore -v <file> to verify which rule is causing a file to be ignored. Use git status --ignored to see all ignored files.

How Git Processes .gitignore

Git evaluates ignore patterns from multiple sources in a specific order: patterns from the command line, patterns from the .gitignore in the same directory, then parent directories up to the repository root, then the global gitignore, and finally .git/info/exclude. Within each file, later patterns override earlier ones. A negation pattern (!) can re-include a file excluded by an earlier rule, but it cannot re-include a file inside an ignored directory.

Understanding this precedence is important when debugging why a file is or isn't being ignored. The git check-ignore -v command is invaluable — it shows exactly which file and line number is responsible for ignoring a given path.

Related Tools

Look up Git commands with the Git Command Reference. Compare file versions with the Diff Checker. Compare environment files with .env Diff. Test gitignore glob patterns with the Regex Tester.