How to Add an .env File to .gitignore

An .env file can hold API keys, passwords, and other values you don’t want in your repository. Add an ignore rule before the first commit, then check that Git is applying it. If the file is already tracked, you’ll need to stop tracking it and handle any exposed secrets separately.

We analyzed 30 comments and questions from Reddit, YouTube and Quora about ignoring environment files and found that 27% mentioned sensitive data.

Step 1: Add .env Patterns to Your .gitignore File

Open the .gitignore file at your repository’s root. If it doesn’t exist, create it. Add a rule that ignores local environment files while letting teammates commit a safe template:

# Local environment files
.env*
!.env.example

The .env* pattern covers .env, .env.local, .env.development, and other files whose names start with .env. The ! at the start of the next rule makes an exception for .env.example, so Git can track that template.

Git reads ignore rules as patterns. A rule without a slash can match a file at any level below the .gitignore file. Later rules can change the effect of earlier ones.

Use a root .gitignore for rules the whole team should share, then commit it with the code. Git’s ignore rules only affect untracked files. They don’t remove a file Git already tracks, and they don’t protect values copied into code, logs, or chat.

A template should show variable names and safe placeholder values, not working credentials. For example, PAYMENT_API_KEY=replace-me tells a teammate what to set without sharing a live key. If your setup needs different access for local, staging, and production values, see how to set per-environment access control for .env files.

Step 2: Check Whether Git Is Ignoring the File

Test the rule before you stage or push code. Run this from the repository root:

git check-ignore -v .env .env.local .env.production

For each ignored file, Git prints the ignore file and matching line. That makes it easy to see whether your root .gitignore rule is working or a different rule is taking effect. If a path produces no output, Git hasn’t found a matching ignore rule for it.

You can also check Git’s status, including ignored files:

git status --short --ignored

An ignored file appears with !! in this output. A file shown as untracked instead needs a matching rule, or it may be outside the pattern you added. Check the spelling and path. For example, .env.local starts with .env, but settings.env does not.

If you suspect the file is already tracked, ask Git directly:

git ls-files -- .env .env.*

If Git prints a path, it’s in the index. That explains why adding an ignore rule didn’t hide it. A tracked file isn’t treated as an ignored, untracked file by the usual status checks. You can also run git check-ignore --no-index -v .env to test a rule without using the index to filter the result.

For personal files that shouldn’t affect the whole team, Git has two other places for ignore patterns: .git/info/exclude for one repository, and a configured global ignore file for your machine. Don’t use either as a substitute for the shared project rule. A teammate who clones the project won’t inherit your personal exclusions.

And don’t use git update-index --assume-unchanged or --skip-worktree to hide a secret. Those flags can be useful for local changes to a tracked config file, but they don’t remove that file from the repository or its history.

Step 3: Stop Tracking an .env File Already in Git

If Git already tracks the file, adding a pattern won’t stop it from being committed. Remove it from Git’s index while keeping your local copy:

git rm --cached .env

The --cached flag stages the file’s removal from the repository but leaves the file on your computer. Add the .gitignore rule if you haven’t already, then commit both changes:

git add .gitignore
git commit -m "Stop tracking local environment file"

For a tracked folder of local config files, use git rm --cached -r path/to/folder. Check the path before running it. The -r option applies the removal to everything inside that folder.

Tell your teammates before they pull the commit. Git may remove their tracked copy from their working directory. They should save any values they still need, then build a local file from the committed template. A shared .env.example makes that handoff less error-prone.

This change only affects future commits. Earlier commits still contain the file, and a new commit that deletes it won’t erase those earlier copies. For a clearer explanation of the distinction, see why removing an .env file from the latest commit may not be enough.

If the file held real credentials, treat them as exposed and rotate them before spending time on history cleanup. If you also need to remove the old content from repository history, a history-rewriting tool such as git filter-repo can rewrite commits. Coordinate with your team first: rewritten history changes commit IDs, and existing clones may still hold the old version.

Step 4: Rotate Secrets If an .env File Was Exposed

If a committed .env file contained a real key or password, assume someone could have copied it. Deleting the file from the current branch won’t make its old values safe again. Rotate or revoke the exposed credentials first.

Work through the file value by value. Identify each key, token, password, or connection string, then find the service that issued it. Revoke the old value or generate a replacement there. Don’t wait for a history rewrite before doing this; the old credential can remain usable in existing clones or copies.

Next, put the replacement value where the app needs it. Update your local environment file, deployment settings, or CI secret store. Check that the app works with the new value before removing any temporary safety measures. If the credential has different scopes for development and production, rotate each exposed value in the right environment.

Then review the account or service that the credential could access. Check available activity records for unexpected sign-ins, API use, data access, or changes. The review should match the credential’s permissions. A key limited to one test service calls for a different check than a credential with production access.

Once access is contained, remove the file from Git going forward and decide whether history should be rewritten. A history rewrite can reduce casual exposure in the repository, but it can’t recall copies already made. Tell collaborators what changed and what they need to do before they sync their local branches.

Secret scanning and push protection can add another check before a credential reaches a shared repository. They’re a safety net, not a replacement for ignoring local files or rotating an exposed key. If a scanner flags a value, verify whether it’s live and treat it as a real incident until you know otherwise.

Step 5: Share Environment Variables Without Committing Secrets

Commit the shape of your configuration, not its secret values. A .env.example file can name the variables an app needs and give safe placeholders. Teammates can copy it to a local .env file, then add their own values.

cp .env.example .env

Keep the template current as the app changes. When a pull request adds a required variable, update the example in the same change. Otherwise, a new developer may clone the project and have no clear way to tell which settings are missing.

For CI, put secrets in the CI platform’s secret store rather than committing a .env file. Give a workflow only the values it needs, and avoid printing secrets in logs. Redaction helps with known values, but it can’t make every transformed or combined value safe to print.

Watch for variables that a frontend build copies into browser code. Names with prefixes such as VITE_ or NEXT_PUBLIC_ are often intended for public values. Don’t put a private API key or password in a variable that ships to every user’s browser.

A local file can still be useful for development, but it gets harder to keep copies in sync as a team grows. EnvManager encrypts and version-controls .env files, with role-based access and syncing to local machines and CI/CD pipelines. We built it to reduce manual copying while keeping team access under control.

EnvManager gives your team one central place for environment files and team syncing. That setup can help when developers need the same approved values without passing secrets through pull requests or chat. For access rules, give each person and workflow only the values they need.

If you keep local .env files, leave them ignored and commit only the safe template. If your team needs central control, compare that workflow with a managed secret store and choose one place to own updates.

FAQ

What should I add to .gitignore for .env files?

Add .env* to ignore files whose names start with .env, then add !.env.example if you want to commit a safe template. This covers common local variants such as .env.local and .env.development. Check the pattern with git check-ignore -v .env.local before you rely on it.

Why is my .env file still tracked after I added it to .gitignore?

Git keeps tracking files that are already in its index, even after you add an ignore rule. Run git ls-files -- .env .env.* to check. If the file is tracked, use git rm --cached .env and commit the change. That stops future tracking while leaving your local file in place.

Does deleting an .env file remove its secrets from Git history?

No. A new commit that deletes the file doesn’t remove its content from earlier commits. If it contained a working key or password, revoke or rotate that credential first. You can then consider rewriting repository history, but collaborators’ clones or other saved copies may still contain the old value.

Can I commit an .env.example file?

Yes, if it contains only variable names and safe placeholder values. Don’t copy live API keys, passwords, tokens, or production connection strings into it. Keep the template aligned with the variables the app requires, so teammates can use it to make their own local .env file.

Conclusion

Add .env* and !.env.example to your root .gitignore, then verify the rule with git check-ignore -v. If Git already tracks a secret file, stop tracking it and rotate any exposed credentials. Make those checks part of your first commit and code review.