Both, for different reasons. Git's documentation says patterns that should be shared with every clone belong in the repository's .gitignore, while personal patterns can live in your global excludes file. Ignoring .env does not help if the file is already tracked, so check that too.
Where Git looks for ignore rules
The gitignore documentation lists several sources: a .gitignore in the repository, the $GIT_COMMON_DIR/info/exclude file, and a global file named by the core.excludesFile setting, which defaults to $XDG_CONFIG_HOME/git/ignore. Lower level files override higher ones for the directory they cover.
The manual spells out the purpose of each. Patterns that other developers also want to ignore go in .gitignore, which travels with the repository. Patterns specific to one repository that need not be shared go in info/exclude. Personal patterns that apply everywhere belong in the global file.
What to put where
| File | Scope | Good for |
|---|---|---|
| .gitignore in the repo | Everyone who clones | .env, local config, build output |
| info/exclude | Your clone only | A scratch file for one project |
| Global excludes file | Every repo on your machine | .env, editor settings, key files |
Putting .env in the project file protects teammates who have no global setup, and protects CI checkouts. A global rule adds protection in repositories you touch only once, where nobody wrote an ignore file.
Set up a global file
Create the file and tell Git about it:
git config --global core.excludesFile ~/.config/git/ignore
Then add lines such as .env, .env.local and *.pem. Keep the list short and meaningful. If you commit a template such as .env.example, add an exception line so it is not swallowed by a pattern.
The limit you must remember
The documentation says files already tracked by Git are not affected by ignore rules. If someone committed .env last month, adding it to an ignore file today changes nothing for that file. To stop tracking a file, the manual says to use git rm --cached to remove it from the index, then add the name to the ignore file.
That removes it from future commits, not from history. A secret in an old commit is still readable, so rotate it.
A one minute check
Run git ls-files | grep -i env in each active repository and look at what is tracked. Then run git check-ignore -v .env to see which rule, if any, covers the file. Fix gaps in the shared file first, then add your personal backstop.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Is a global ignore enough?
It covers your machine only. Teammates and CI need the rule in the repository.
Does ignoring a file remove it from history?
No. Ignore rules only affect untracked files. Rotate any secret that was committed.
How do I stop tracking a committed file?
The manual says use git rm --cached, then add it to the ignore file.
Sources
Last reviewed: 19 October 2026.
