UtilitiesHub

Git Ignore Generator

Generate a clean, editable .gitignore file for your project by combining common templates. Pick one or more stacks, review the generated rules, add your own patterns, then copy or download the final file.

Ignore dependencies, build output, logs, and local env files.

Explore More

Go straight to the formatter, validator, encoder, generator, or developer utility you need.

Coding Tools

.gitignore Generator — Create the Right .gitignore for Your Project Stack

Every Git repository needs a .gitignore file. Without one, a git add . will eagerly stage everything in the project directory — including your node_modules/ folder (potentially hundreds of megabytes of third-party packages), your .env file (containing database passwords, API keys, and other secrets that should never be committed), IDE-specific folders like .idea/ or .vscode/ (different for every developer), compiled bytecode, build artifacts, and log files. These files either shouldn't be in version control at all, can be regenerated from source, or are specific to one developer's local setup and would cause unnecessary conflicts for others.

A well-crafted .gitignore keeps your repository small and focused, makes your commit diffs meaningful (you see only actual code changes, not constant regenerated file noise), keeps build-specific files from cluttering the history, and — most critically — keeps secrets off GitHub, GitLab, and Bitbucket where they're publicly accessible or visible to anyone with repository access. This generator combines templates for the most common languages, frameworks, and development tools, merges them into a single clean file, and lets you copy or download the result.

What Belongs in Every Project's .gitignore

Regardless of language or framework, certain categories of files should almost always be excluded from version control:

Environment and secrets files: .env, .env.local, .env.production, .env.*.local — these files contain configuration specific to one environment (database connection strings, API keys, third-party service credentials, JWT secrets). They must never be committed. Use a .env.example file with placeholder values as documentation for what variables are required, and commit that instead.

Dependency directories: node_modules/ (Node.js), vendor/ (Composer/PHP), .venv/ and __pycache__/ (Python), .bundle/ (Ruby), target/ (Java/Rust) — these directories are reproduced entirely from the lock file (package-lock.json, composer.lock, etc.) by running the package manager install command. Committing them adds enormous bloat to the repository and makes every diff noisy with auto-generated files.

Build output: dist/, build/, out/, .next/, .nuxt/, compiled *.class or *.o files — these are generated from source files and should be reproducible by running the build command. Including them in version control means the build output gets committed on every build, making history cluttered and diffs meaningless.

IDE and editor metadata: .idea/ (JetBrains IDEs), .vscode/ (VS Code, though some settings are worth sharing), *.suo, *.user (Visual Studio), .DS_Store (macOS Finder metadata), Thumbs.db (Windows Explorer thumbnails) — these are specific to each developer's local setup and would constantly appear as unstaged changes for everyone else on the team.

Logs and temporary files: *.log, logs/, tmp/, temp/ — log files change on every request and carry no useful history in version control. They should be written to a location outside the project directory or explicitly ignored.

.gitignore Pattern Syntax — Complete Reference

.gitignore uses a glob-based pattern syntax. Understanding the syntax prevents common mistakes:

A pattern with no slash matches anywhere in the tree: *.log ignores all .log files in any subdirectory. A trailing slash means directory only: dist/ ignores the directory but not a hypothetical file named dist. A leading slash anchors the pattern to the .gitignore file's location: /config.local.php only matches at that level, not in subdirectories.

* matches any sequence of characters except a slash (stays within one directory level). ** matches across directory levels: **/logs/ matches a logs/ directory anywhere in the project. ? matches any single character. [abc] matches any one of the characters in the brackets.

A leading ! negates a pattern, un-ignoring files that would otherwise be matched: if you ignore all files in config/ but want to commit config/example.php, you add !config/example.php after the ignore rule. Note that you cannot un-ignore a file inside a directory that is itself ignored — the parent directory ignore takes precedence and the negation has no effect.

Blank lines are ignored. Lines starting with # are comments. Patterns are case-sensitive on Linux and macOS file systems, and case-insensitive on Windows — which can cause cross-platform issues. Be explicit about casing in teams that use mixed operating systems.

Global vs. Repository-Level .gitignore

There are two places where gitignore rules can be defined:

Repository-level .gitignore: Placed in the root of the repository, committed to the repo, and shared across all contributors. This is for project-specific exclusions — node_modules/, vendor/, .env, build directories, and language-specific generated files. Every developer cloning the repository gets these rules automatically.

Global .gitignore: A personal ignore file on your local machine that applies to all your repositories. Configured with git config --global core.excludesfile ~/.gitignore_global. This is the right place for IDE-specific exclusions that are personal to you (.idea/, .vscode/ if not shared) and OS-specific files (.DS_Store, Thumbs.db) — things that are irrelevant to the project itself and shouldn't clutter the shared repository-level file with developer-tool-specific rules.

Frequently Asked Questions About .gitignore

No. .gitignore only prevents untracked files from being staged. If a file is already committed and tracked by Git, adding it to .gitignore has no effect — Git will keep tracking it. To stop tracking a file that's already in the repo, you need to remove it from Git's index first: git rm --cached filename (for a single file) or git rm -r --cached . followed by a fresh git add . to re-stage everything according to the updated .gitignore. Then commit the removal.
Yes, always. The .gitignore is part of the project configuration and should be committed so every contributor and CI/CD environment shares the same ignore rules. IDE-specific or personal ignores that only apply to your local setup (like ignoring your personal notes file) should go in your global gitignore instead: ~/.gitignore_global configured with git config --global core.excludesfile ~/.gitignore_global.
Use a path relative to the .gitignore file, anchored with a slash. For example, /storage/logs/ in a root-level .gitignore ignores the logs folder only in storage/logs/, not any other logs/ folder in the project. Alternatively, place a separate .gitignore file directly inside that subdirectory — patterns in that file are relative to that directory.
The most common reason is that the file is already tracked (see the first FAQ). Other causes: the pattern syntax is wrong (test it with git check-ignore -v filename); the file is in a subdirectory but the pattern doesn't account for that; a negation pattern (!) earlier in the file is overriding the ignore; or the .gitignore file itself has Windows line endings on a Linux server, which can confuse some Git versions. Run git check-ignore -v yourfile to see exactly which rule is or isn't matching.
Treat all secrets in that file as compromised immediately — rotate API keys, change passwords, and revoke tokens regardless of whether the repository is public or private. Then remove the file from Git history: add it to .gitignore, run git rm --cached .env, commit that change, and then use git filter-repo or BFG Repo-Cleaner to purge it from the full commit history. Force-push the rewritten history. If the repo was ever public or cloned by others, assume the secrets were already seen.