.gitignore Complete Templates: 20 Common Scenarios

.gitignore Complete Templates: 20 Common Scenarios for Every Developer

In the world of version control, the .gitignore file is your first line of defense. It is the silent guardian of your repository, ensuring that your Git history remains clean, your repository size stays manageable, and—most importantly—your sensitive credentials never leak into the public domain.

A poorly configured .gitignore can lead to "repository bloat," where massive dependency folders like node_modules or heavy build artifacts like .exe files are accidentally committed. Even worse, a missing entry for .env files can result in a catastrophic security breach, exposing API keys, database passwords, and secret tokens to anyone with access to the repository.

Whether you are a frontend engineer, a data scientist, or a DevOps specialist, having a reliable set of .gitignore templates is essential. In this comprehensive guide, we will explore the syntax, the logic, and provide 20 complete, production-ready templates for the most common development scenarios.

If you find yourself struggling to manually curate these rules, you can use the gitignore generator to quickly create a customized file based on your specific tech stack.

---

Understanding the Power of .gitignore

Before diving into the templates, it is crucial to understand what .gitignore actually does. It does not "delete" files from your computer; rather, it instructs Git to pretend those files do not exist for the purpose of tracking changes.

The Core Purpose of Ignoring Files

There are three primary reasons why a developer must ignore certain files:

1. Security and Privacy: This is the most critical reason. Files containing secrets, such as .env, auth.json, or id_rsa, must never be committed. Once a secret is pushed to a remote repository (like GitHub), it is considered compromised, even if you delete it in a subsequent commit.
2. Dependency Management: Modern development relies on package managers (npm, pip, Maven). These tools download dependencies into specific folders. Committing these folders is redundant because they can be reconstructed using a lockfile (like package-lock.json or Gemfile.lock). Ignoring them keeps your repo lightweight.
3. Build Artifacts and Temporary Files: Compilers and bundlers generate output files (like .dist, .class, or .pyc). These files are derivatives of your source code. Including them creates unnecessary merge conflicts and bloats the Git history every time you run a build.

The Syntax of Git Ignoring

To use .gitignore effectively, you must master its pattern-matching syntax. Understanding these rules prevents you from accidentally ignoring a file you actually need.

• The Asterisk (*): A wildcard that matches zero or more characters. For example, *.log ignores all files ending in .log.
• The Double Asterisk (**): Matches nested directories. **/logs/*.txt will find all .txt files inside any folder named logs, regardless of how deep they are in the directory tree.
• The Question Mark (?): Matches exactly one character. file?.txt would match file1.txt but not file10.txt.
• The Exclamation Mark (!): This is the "negation" operator. It tells Git not to ignore a file that was previously matched by a pattern. This is useful when you want to ignore an entire folder except for one specific file.
• The Slash (/): If a pattern starts with a slash, it matches relative to the location of the .gitignore file. If it ends with a slash, it only matches directories.

---

Mastering .gitignore Syntax: A Deep Dive

To write professional-grade .gitignore files, you need to move beyond simple file extensions. A senior developer knows how to handle complex directory structures and edge cases.

Handling Directory-Specific Rules

One common mistake is ignoring a directory but forgetting that Git might still track files within it if they were already staged.

If you use folder/, you ignore the entire directory. However, if you want to ignore everything in logs/ except a keep.txt file, you must use the negation pattern:

# Ignore the entire logs directory
logs/

# But do not ignore this specific file
!logs/keep.txt

The Danger of Global vs. Local Patterns

It is important to distinguish between patterns that apply to your entire project and patterns that apply to your entire machine.

• Project-level .gitignore: Resides in your project root. It is committed to the repo and shared with the team. This is where your language-specific rules (like node_modules/) belong.
• Global .gitignore: Resides in your user home directory. This is where you put OS-specific rules (like .DS_Store for macOS) that apply to every project you work on, regardless of the language.

Managing Files That Are Already Tracked

A common "gotcha" for developers is adding a file to .gitignore after it has already been committed to the repository. Git will continue to track changes to that file because the .gitignore rule only applies to untracked files.

To fix this, you must remove the file from the Git index (the staging area) without deleting it from your local disk. Use the following command:

# Remove a single file from tracking
git rm --cached path/to/your/file.txt

# Remove an entire directory from tracking (e.g., node_modules)
git rm -r --cached node_modules/

# After running this, commit the change
git commit -m "Fix: Stop tracking ignored files"

---

The 20 Essential .gitignore Templates for Modern Development

To make this guide practical, I have categorized 20 common scenarios into logical groups. You can mix and match these patterns based on your specific project requirements.

Group 1: Web Development (Frontend & Fullstack)

1. Node.js (npm/yarn/pnpm)

The most critical rule here is ignoring node_modules. It is massive and easily reproducible.

node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*
coverage/
build/
dist/

2. React/Vue/Angular (Bundlers)

When using Webpack, Vite, or Parcel, you must ignore the output directories.

# Build outputs
dist/
build/
out/
# Testing coverage
coverage/
# Environment variables
.env
.env.local
.env.development.local
.env.test.local
.env.production.local

3. Svelte/SvelteKit

SvelteKit has specific build folders and generated types.

.svelte-kit/
build/
.env
.env.*.local

4. TypeScript

TypeScript generates .js files from .ts files during compilation. You should never commit the compiled output.

*.tsbuildinfo
# If you are compiling to a specific folder
dist/

Group Markup: Backend & Data Science

5. Python (General)

Python creates several types of cache and bytecode files that clutter the repo.

__pycache__/
*.py[cod]
*$py.class
*.so
.Python
env/
venv/
.venv/
pip-log.txt

6. Django

Django projects involve databases and secret keys that must stay local.

*.log
*.sqlite3
local_settings.py
media/
static/
.env

7. Flask

Similar to Django, but often focuses on virtual environments.

venv/
.venv/
instance/
.env
*.pyc

8. Java (Maven/Gradle)

Java builds generate massive amounts of .class files and JARs.

# Maven
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
release.properties
*.jar
*.war

# Gradle
.gradle/
build/

9. Go (Golang)

Go produces binaries that are platform-specific and should not be shared.

# Binaries
*.exe
*.exe~
*.dll
*.so
*.dylib
# Test coverage
*.out

10. Ruby (Rails)

Ruby on Rails has a very specific structure for logs and temporary files.

/log/*
/tmp/*
/public/assets
/public/packs
/public/packs-test
/node_modules
/vendor/bundle
.env

11. PHP (Composer)

The vendor directory is the PHP equivalent of node_modules.

/vendor/
.phpunit.result.cache
composer.lock (Note: Some teams prefer to commit this, but ignore it if using specific workflows)
*.log

Group 3: Mobile & Desktop Development

12. Android (Gradle/Kotlin)

Android Studio generates many local configuration files.

*.iml
.gradle/
local.properties
.idea/caches/
.idea/libraries/
gen/
build/

13. iOS (Swift/Objective-C)

CocoaPods and Xcode generate large, unnecessary workspace files.

Pods/
*.moved-aside
*.xcuserstate
*.xcworkspace/
DerivedData/

14. Flutter/Dart

Flutter builds are heavy and contain platform-specific artifacts.

.dart_tool/
.flutter-plugins
.flutter-plugins-dependencies
.packages
build/
*.g.dart

15. C++ (CMake/Make)

C++ compilation produces object files and executables.

*.o
*.obj
*.out
*.app
*.exe
*.dll
*.so
*.dylib
CMakeCache.txt
CMakeFiles/
cmake_install.cmake

16. C# (.NET)

The .NET ecosystem produces many bin and obj folders.

bin/
obj/
*.user
*.suo
*.userosscache
*.sln.docstates

Group 4: DevOps, Cloud, and System-Wide

17. Docker

Docker-related logs and local data volumes should be ignored.

.docker/
# If you mount a local volume for data
data/
logs/
*.log

18. Terraform

Terraform maintains a "state" file that contains sensitive infrastructure info.

*.tfstate
*.tfstate.backup
*.tfvars
*.tfvars.json
.terraform/

19. Kubernetes

Configuration files that contain cluster-specific secrets or local kubeconfigs.

kubeconfig
*.kubeconfig
.kube/

20. System & IDE (The "Universal" Layer)

These should ideally be in your Global .gitignore, but are often found in project-level files.

# macOS
.DS_Store
.AppleDouble
.LSOverride

# Windows
Thumbs.db
desktop.ini

# VS Code
.vscode/
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

# IntelliJ/JetBrains
.idea/
*.iws
*.iml
*.ipr

---

Comparison: Standard vs. Custom vs. Global .gitignore

When deciding where to place your ignore rules, use this comparison table to determine the best strategy for your workflow.

Feature	Project-level .gitignore	Global .gitignore	.git/info/exclude
Scope	Only the current repository.	Every repository on your machine.	Only the current repository.
Visibility	Committed to Git; visible to the team.	Local to your machine; invisible to others.	Local to your machine; invisible to others.
Best Use Case	Language-specific rules (e.g., node_modules).	OS-specific rules (e.g., .DS_Store).	Personal preferences (e.g., specific notes).
Collaboration	Ensures everyone follows the same rules.	Prevents "junk" from entering any repo.	Good for "one-off" ignores you don't want to share.
Complexity	High (requires maintenance per project).	Low (set it and forget it).	Medium (easy to forget it exists).

---

Advanced Git Ignoring Strategies

To truly master Git, you should implement a multi-layered approach to ignoring files.

The "Three-Tier" Strategy

1. Tier 1: The Global Layer. Set up a global .gitignore for your operating system. This prevents you from accidentally committing .DS_Store or Thumbs.db in every single project you ever touch.
   • Command: git config --global core.excludesfile ~/.gitignore_global
2. Tier 2: The Project Layer. Use the .gitignore in your repository root for all language-specific dependencies and build artifacts. This is the "source of truth" for your team.
3. Tier 3: The Personal Layer. If you use a specific tool (like a custom text editor or a local script) that generates files only you use, add those patterns to .git/info/exclude. This keeps your project's .gitignore clean of "personal noise."

Automating Your Workflow

Manually writing these files is error-prone. As your project grows, you might add new technologies (e.g., adding a Python script to a Node.js project). Instead of guessing, use automation.

A great way to streamline this is by using a gitignore generator. This allows you to select multiple templates and merge them into one cohesive file instantly.

---

FAQ: Common .gitignore Questions

1. Why is Git still tracking a file I added to .gitignore?

As mentioned earlier, Git only ignores untracked files. If the file was already committed, you must run git rm --cached <file> to stop tracking it.

2. Should I commit my .gitignore file to the repository?

Yes, absolutely. The .gitignore file is a critical part of the project's configuration. It ensures that every developer on the team (and the CI/CD pipeline) follows the same rules, preventing accidental commits of build artifacts or secrets.

3. Can I ignore only one file within a folder that is otherwise tracked?

Yes. You can use the negation operator (!). For example, if you want to track everything in config/ except config/secret.json, you would write:

config/*
!config/secret.json

4. Is it a good idea to use a global .gitignore?

Yes. It is highly recommended to use a global .gitignore for system-level files like .DS_Store (macOS) or Thumbs.db (Windows). This keeps your project-level .gitignore focused strictly on the application's logic and dependencies.

5. How do I ignore all files with a specific extension?

Use the wildcard asterisk: *.ext. For example, *.log will ignore every file in every directory that ends with the .log extension.

6. Does .gitignore affect files that are already in the Git history?

No. .gitignore only affects files that are not currently being tracked by Git. To remove a file from the history, you would need much more complex tools like git filter-repo or BFG Repo-Cleaner.

---

Conclusion

Mastering .gitignore is a hallmark of a professional developer. It is not merely about "hiding files"; it is about maintaining the integrity, security, and performance of your software development lifecycle. By implementing the 20 templates provided in this guide and adopting a multi-layered strategy (Global, Project, and Personal), you can ensure that your repositories remain clean, scalable, and secure.

Remember: When in doubt, ignore it. If a file is generated by a machine, contains a secret, or is simply a byproduct of your environment, it does not belong in your Git history. For a quick and easy way to generate these files without the manual headache, check out the gitignore generator at Super Tools.