nutilz
🙈

.gitignore Generator

Select your technologies and generate a .gitignore file instantly

Select one or more technologies above to generate your .gitignore file.

🔒 No upload — runs entirely in your browser. Your data never leaves your device.

Related Tools

🤖

Robots.txt Generator

Generate robots.txt files with presets for AI crawlers and SEO.

{}

JSON Formatter

Format, validate and minify JSON with error detection.

⇢

cURL to Code

Convert cURL commands to Python, JavaScript, Go and more.

#

Hash Generator

Generate SHA-1, SHA-256 and SHA-512 cryptographic hashes.

Browse all Developer Tools tools →

What is a .gitignore File?

A .gitignore file is a plain text file placed in the root of your Git repository that instructs Git which files and directories to skip when tracking changes. When you run git status, git add, or git commit, Git silently ignores anything matching a pattern in this file. The ignored files stay on your local machine but never make it into your repository's history.

Without a .gitignore file, every file in your project directory appears as an untracked file when you run git status. Developers then accidentally commit build output, API keys, operating system metadata, and hundreds of megabytes of third-party libraries — things that pollute history, slow down clones, and in the case of secrets, create security vulnerabilities that can never be fully undone.

The .gitignore format is simple, flexible, and supported by every Git client and hosting platform including GitHub, GitLab, and Bitbucket. Every project, from a weekend side project to a production monorepo, should have a thoughtfully crafted .gitignore tailored to its specific stack — which is exactly what this generator helps you create in seconds.

How to Use This .gitignore Generator

  1. 1.Select your technologies from the grid above. Use the search box to find a specific language, framework, or editor quickly, or click a category pill to filter by type.
  2. 2.Select multiple technologies freely — a full-stack project might combine Node.js + React + VS Code + macOS, for example. Each template's content is appended with a clear comment header.
  3. 3.Review the generated output in the preview panel. The content updates instantly as you select or deselect technologies.
  4. 4.Click Download .gitignore to save the file directly, or Copy to paste it manually.
  5. 5.Place the file named exactly .gitignore in your project root — the same directory that contains your .git/ folder. Then run git status to confirm the excluded files no longer appear as untracked. Commit the .gitignore file itself so your whole team benefits from the same rules.

For most projects, you will want to pick at least one language template, one IDE template, and your OS template. This three-layer approach covers: language-specific build artifacts (node_modules/, __pycache__/), editor configuration files (.idea/, .vscode/), and OS metadata files (.DS_Store, Thumbs.db).

Understanding .gitignore Syntax: Key Patterns Explained

Git uses a simplified glob pattern syntax for .gitignore rules. Understanding the rules prevents accidental over-ignoring or under-ignoring.

  • *.log — A pattern with no slash matches files of that name anywhere in the entire repository tree. This ignores every .log file in every subdirectory.
  • dist/— A trailing slash indicates a directory. Git ignores the dist/ directory and everything inside it, but not a file literally named "dist" (without a slash).
  • /build.sh — A leading slash anchors the pattern to the repository root. This only ignores build.sh at the root level, not at src/scripts/build.sh.
  • !important.log — An exclamation mark negates a pattern, un-ignoring files that an earlier rule would match. If you have *.log above and !important.log below it, important.log will be tracked normally.
  • **/temp— Double asterisk matches any number of path segments. This ignores any file or directory named "temp" anywhere in the repository, regardless of depth.
  • src/**/*.test.js — Combined wildcards are powerful. This ignores all .test.js files anywhere under the src/ directory.
  • [Dd]ebug/— Square brackets match any of the enclosed characters. This matches both "Debug/" and "debug/" — useful for case-insensitive matching on systems that differ in filename case sensitivity.

One important ordering rule: if a parent directory is ignored, Git never checks patterns for files inside it — even a negation pattern cannot un-ignore a file inside an already-ignored directory. To override an ignored parent, you would need to also un-ignore the parent itself.

Global .gitignore vs. Project .gitignore: Which to Use

Git supports two levels of ignore rules: project-level (the .gitignore in your repository) and global (a machine-wide file for personal tooling preferences). Knowing when to use each keeps your repository clean and your ignore rules maintainable.

Project .gitignore lives in your repository and is committed alongside your code. It contains patterns relevant to the entire team: language artifacts (node_modules/, __pycache__/), framework build output (dist/, .next/), environment files (.env), and secrets. Because every collaborator clones this file, it ensures consistent ignore behavior across the team regardless of what editor or OS they use.

Global .gitignore(~/.gitignore_global) applies to every repository on your personal machine. Use it for personal tooling noise: .DS_Store (macOS Finder metadata), Thumbs.db (Windows Explorer thumbnails), .idea/ or .vscode/ (your IDE), .history/ (local file history extensions). These should not be in your project's .gitignore because not every collaborator uses the same editor or OS — adding .DS_Store to a shared repository means Windows users see an unnecessary pattern, and the project file grows stale over time.

To configure a global gitignore, run: git config --global core.excludesfile ~/.gitignore_global. Then add your personal patterns to that file. The patterns take effect immediately in every repository on your machine without requiring a commit.

Why .gitignore Patterns Matter for Security

Accidentally committing a secret to a Git repository — even for a few minutes before it is deleted — is a serious security incident. Secrets committed to Git are typically leaked in three ways: the file's diff appears in commit history, secrets show up in git log -p output, and in public repositories, automated credential scanners like GitHub Secret Scanning and truffleHog find and report them within seconds of the push.

Removing a secret from the latest commit does not remove it from Git history — every past commit still contains it. Complete removal requires rewriting history with git filter-repo and force-pushing, which disrupts collaborators and cannot guarantee the secret was not already cloned, cached, or archived.

Patterns to always include in every project's .gitignore:

  • .env and .env.* — environment variable files containing API keys, database URLs, and OAuth secrets
  • *.pem, *.key, *.p12 — private keys and certificates
  • config/secrets.yml, config/master.key — Rails and similar framework credential files
  • auth.json, credentials.json — service account files for cloud providers

Layer your protection: use .gitignore to prevent accidental commits, use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for runtime injection, and use a pre-commit hook or detect-secrets to block commits that look like they contain credentials before they ever reach a remote.

Common .gitignore Patterns Explained by Language

Different ecosystems generate different categories of files. Here is why the most common patterns appear in each template:

  • Node.js — node_modules/
    Every npm, Yarn, or pnpm install populates node_modules/ with thousands of files. A typical Next.js project has 30,000+ files in this directory. Committing it bloats repository size by hundreds of megabytes, creates cross-platform binary conflicts, and slows every git operation. Use package-lock.json, yarn.lock, or pnpm-lock.yaml to reproduce the exact dependency tree on any machine.
  • Python — __pycache__/ and *.pyc
    Python compiles .py source files to bytecode (.pyc) stored in __pycache__/ directories. These files are platform-specific (different Python versions produce incompatible bytecode) and fully regenerated on import. Committing them means constant merge conflicts and binary diffs that add no value to history. The .venv/ and venv/ directories are virtual environments containing Python itself and all installed packages — always reproduce these with pip install -r requirements.txt.
  • Java — target/ and *.class
    Maven compiles Java source files (.java) into bytecode (.class) and packages them in the target/ directory. These files are architecture-specific and 100% reproducible by running mvn clean package. Committing them makes your repository binary-heavy and causes spurious diffs on every build.
  • Go — vendor/
    Go modules support vendoring dependencies into a vendor/ directory so builds work without network access. While some teams commit vendor/ intentionally for reproducibility, most prefer the standard module cache (go.sum provides the lockfile). The Rust equivalent is the target/ directory which can easily exceed 1 GB for larger Rust projects.

What Files Should Always Stay Out of Version Control

Regardless of your stack, these categories should be in every .gitignore:

  • Secrets and credentials..env files, private keys (*.pem, *.key), service account JSON files, and any config file that contains a real password or token. Rotate immediately if accidentally committed.
  • Build artifacts.dist/, build/, out/, target/, __pycache__/, *.class, *.o — anything generated from source code is reproducible and belongs in your CI/CD pipeline, not in history.
  • Dependency directories.node_modules/, vendor/, .venv/, Pods/ — use the corresponding lockfile to reproduce these deterministically.
  • IDE and editor metadata..idea/, .vscode/, *.suo, *.user — personal to each developer's machine and tooling. Use a global gitignore for these.
  • OS-specific files..DS_Store (macOS), Thumbs.db, desktop.ini (Windows), .directory (Linux/KDE) — generated by the operating system and meaningless to other collaborators.
  • Log and temporary files.*.log, npm-debug.log, *.tmp — transient files that change on every run and add noise to your repository history.

Frequently Asked Questions

What is a .gitignore file?+
A .gitignore file is a plain text file in your repository's root directory that tells Git which files and directories to ignore when tracking changes. When you run git status, git add, or git commit, Git skips any file matching a pattern in .gitignore and does not add it to your repository. This prevents build artifacts (like node_modules/ or dist/), secrets (like .env files), editor-specific metadata (like .DS_Store or .idea/), and other generated files from cluttering your version history. Every project should have a .gitignore file tailored to the languages, frameworks, and tools it uses.
How do I create a .gitignore file for my project?+
To create a .gitignore file: (1) Select your languages, frameworks, and editors in this generator. (2) Click Copy or Download .gitignore to get the generated content. (3) Save the file as .gitignore (with the dot prefix, no extension) in the root directory of your project — the same folder that contains your .git/ directory. (4) Run git status to confirm the ignored files no longer appear as untracked. (5) Commit the .gitignore file itself to your repository so your whole team shares the same ignore rules. If you are adding .gitignore to an existing project that already tracks some files you want to ignore, you will also need to run git rm --cached on those files.
What is the syntax for .gitignore patterns?+
Git uses a simplified glob pattern syntax for .gitignore rules. A pattern with no slash matches files anywhere in the repository tree — for example, *.log ignores all .log files in every directory. A trailing slash means a directory — dist/ ignores the dist directory but not a file named dist. A leading slash anchors the pattern to the repository root — /build.sh only ignores build.sh at the root, not in subdirectories. An exclamation mark negates a pattern — !important.log un-ignores a file matched by an earlier pattern. Double asterisk (**) matches any number of path segments — **/temp ignores any file named temp in any directory.
Why should I never commit node_modules or vendor directories to Git?+
Node_modules (Node.js) and vendor (PHP, Go) directories contain third-party dependencies that are fully reproducible from a manifest file — package.json for Node or composer.json for PHP. Committing them to Git creates several problems: repository size bloats by tens to hundreds of megabytes, pulling changes becomes slow, Git history becomes polluted with thousands of irrelevant file changes on every dependency update, and collaborators on different operating systems may get binary conflicts. Instead, commit package.json, package-lock.json (or yarn.lock), and run npm install to restore dependencies. Your CI/CD pipeline should do the same. Keeping generated, reproducible artifacts out of Git is a core version control best practice.
What is a global .gitignore file and how do I set one up?+
A global .gitignore file applies ignore rules to every Git repository on your machine, regardless of project. It is ideal for editor-specific files and OS artifacts that are personal to your machine, not the project — things like .DS_Store (macOS), Thumbs.db (Windows), .idea/ (JetBrains IDEs), or .vscode/ (VS Code). To create one: (1) Create a file at ~/.gitignore_global (or any path you prefer). (2) Run: git config --global core.excludesfile ~/.gitignore_global. (3) Add your personal patterns to that file. These rules take effect in every repository without requiring a per-project .gitignore entry. Project-level patterns for build artifacts, language-specific files, and environment files belong in the repository .gitignore instead, so all team members benefit.
How do I stop tracking a file that is already committed to Git?+
Adding a file to .gitignore only prevents future tracking — it does not un-track files already committed to your repository. To stop tracking an already-committed file: (1) Add the file path to .gitignore. (2) Run: git rm --cached path/to/file — this removes the file from Git's index (staging area) but keeps it on your local disk. For a directory, use: git rm -r --cached path/to/directory. (3) Commit the change: git commit -m "Stop tracking [file]". After this, Git will no longer track changes to that file, and it will remain on your local filesystem. Note that the file's history up to this point is still stored in your repository — if the file contained secrets, rotate those credentials immediately and consider using a tool like git-filter-repo to scrub history.
What files should I always exclude from version control?+
You should always exclude: (1) Secrets and credentials — .env files, API keys, private keys, database passwords, OAuth tokens, and config files containing credentials. These belong in a secrets manager or environment variable system. (2) Build artifacts and generated files — dist/, build/, target/, __pycache__/, *.class — these are reproducible from source code. (3) Dependency directories — node_modules/, vendor/, .venv/ — reproducible from lock files. (4) IDE and editor metadata — .idea/, .vscode/, *.suo, .project — personal to each developer. (5) OS-specific files — .DS_Store, Thumbs.db, desktop.ini — generated by your operating system. (6) Log files — *.log, npm-debug.log — transient and not useful in history. Committing any of these slows down your repository and creates unnecessary merge conflicts.