What .env is for
A .env file holds the actual environment variables for one specific environment: real database URLs, API keys, secrets, and feature flags. It is loaded at runtime by a dotenv library or your framework and is specific to a machine or deployment.
Because it contains secrets and environment-specific values, .env should never be committed to version control. It is almost always listed in .gitignore, and each developer or deployment maintains its own copy.
What .env.example is for
A .env.example (sometimes .env.sample or .env.template) is a committed, shareable blueprint. It lists every variable the application needs, usually with empty values or safe placeholders rather than real secrets.
Its job is documentation and onboarding: a new developer copies it to .env and fills in real values. Because it is in version control, code review keeps it honest, so it becomes the canonical list of "what this app expects to be configured".
The key differences at a glance
Committed: .env.example yes, .env no. Contains secrets: .env yes, .env.example no. Purpose: .env is real runtime config, .env.example is a documented contract. Number of copies: one .env.example for the repo, many .env files (local, dev, qa, prod).
The two files share the same keys but differ in values. That is exactly why drift happens: it is easy to update one and forget the other, since git only ever sees the example.
How to keep them in sync
Whenever you add or rename a variable in code, update .env.example in the same commit so reviewers see it. Then have every developer re-check their local .env against the new template.
You can automate the check: load .env.example as the template and your .env as the environment in the validator on this site, and it will list any key that is missing, undocumented, duplicated, or malformed. Keeping the example accurate and the real files validated against it is the whole game.