How to Ignore Environment Variables and Secrets Safely in .gitignore

To safely ignore environment variables and secrets in .gitignore, add patterns like .env and .env.* to exclude all dotenv files while using !.env.example to track a template, then verify rules with git check-ignore.

The github/gitignore repository provides community-vetted patterns for excluding sensitive configuration files across languages and frameworks. Learning how to ignore environment variables and secrets safely in .gitignore prevents API keys and passwords from leaking into version control while maintaining a usable template for your development team.

Block Environment Files While Keeping Templates

Ignore All Dotenv Variants

Start by ignoring the base .env file and any variants that start with .env.. According to the source code in Node.gitignore (lines 68-71), the canonical pattern is:

# dotenv environment variable files

.env
.env.*

This captures files like .env.local, .env.development, and .env.production used by libraries such as dotenv.

Re-include an Example Template

Developers need to know which variables are required without seeing actual secrets. Use the negation pattern ! to track an example file:

!.env.example

As implemented in Node.gitignore at line 71, this exception ensures .env.example (containing keys without values) remains in version control while blocking real environment files.

Add Framework-Specific Environment Patterns

Different frameworks use distinct naming conventions for stage-specific configuration. The github/gitignore templates include targeted rules for popular stacks:

• Next.js: Nextjs.gitignore (lines 27-29) adds .env*.local to ignore local overrides while allowing committed staging files.
• NestJS: Nestjs.gitignore (lines 16-20) explicitly lists .env.development, .env.test, and .env.production.
• Laravel: Laravel.gitignore (lines 19, 27-28) covers .env.backup and .env.production.
• Python: Python.gitignore (lines 151-153) ignores .env and .envrc for direnv users.
• Rails: Rails.gitignore (lines 27-30) handles .env and .env*.local for Ruby projects.

Include the relevant patterns from these templates to ensure comprehensive coverage.

Isolate Personal Secrets with Global Ignores

For files containing private API keys that should never be shared, avoid adding them to the project's shared .gitignore. Instead, use your global ignore file or the repository-specific exclude file:

# Add to ~/.gitignore_global or .git/info/exclude

.secrets/
*.key
*.token

This keeps personal configuration out of the shared repository history while still protecting you from accidental commits.

Validate Exclusions with git check-ignore

Before committing, verify that your patterns correctly block secrets and allow templates:

git check-ignore -v .env
git check-ignore -v .env.example

The first command should output the matching rule and line number, confirming exclusion. The second should return nothing, indicating the file is tracked.

Summary

• Add .env and .env.* to your .gitignore to block all dotenv files according to Node.gitignore lines 68-71.
• Use !.env.example to re-include a template file that documents required variables without exposing values.
• Incorporate framework-specific patterns from Nextjs.gitignore, Nestjs.gitignore, Laravel.gitignore, Python.gitignore, and Rails.gitignore for stage-specific files.
• Store personal secrets in ~/.gitignore_global or .git/info/exclude rather than the project's .gitignore.
• Run git check-ignore -v <file> to verify rules are working as expected.

Frequently Asked Questions

What is the safest pattern to ignore all .env files in Git?

Add .env and .env.* to your .gitignore. This combination catches the base file and all variants like .env.local or .env.production, as recommended in the Node.gitignore template.

How do I keep an example environment file in version control?

Use the negation pattern !.env.example placed after your .env.* rule. This tells Git to track the example file despite the preceding wildcard exclusion, allowing you to document required keys without exposing secrets.

Where should I put personal API keys that I don't want to share?

Add personal secrets to your global Git ignore file at ~/.gitignore_global or the repository-specific .git/info/exclude. This prevents accidental commits without polluting the shared project's .gitignore with user-specific paths.

How can I test if my .gitignore rules are working correctly?

Run git check-ignore -v <filename> from your repository root. If the file is ignored, Git outputs the specific rule and line number; if nothing prints, the file is currently tracked or untracked but not ignored.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}