您的.env文件包含非常敏感的信息（至少是您的应用密钥）。您不希望在版本控制中包含这些信息，因为每个人都可以看到这些信息，并可能使用它们攻击您的站点。
考虑一下可能存储在那里的数据库信息，或者电子邮件密钥或密码。此外，您在.env文件中使用的信息也可能需要在不同的环境中更改，因此无论如何您都需要更改值。
你应该怎么做呢？
创建一个.env.example文件，在这个文件中放置.env的所有密钥。
例如

APP_ENV=local
APP_DEBUG=true
APP_KEY=SomeRandomString
APP_URL=http://localhost

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

在这里你可以看到一个文件，其中有所有必要的信息，但没有任何敏感信息，然后有人可以将这个.env.example复制到.env并更改值。

这里的答案和很多文章都说.env包含敏感信息，所以不应该把它放在源代码管理中，但事实是.env不仅仅包含敏感信息，它也可能包含典型的设置配置，你可以把敏感信息放在git中，而把其他所有的设置都放在git中。
有些人建议在git中放.env.example，我实际上遵循了一段时间，但发现它相当“不方便”，特别是对新加入团队的家伙来说，当他们检查代码时，发现代码无法运行，然后他们从其他老家伙那里复制.env（而不是来自.env.example并进行必要的更改。）B/c用于开发环境，即使是敏感信息（如API密钥/DB密码）也会共享。
通常整个开发团队都有一个API键和一个DB设置，我经常看到这种情况发生，这让我怀疑. env. example的使用。
所以现在我把.env放在git中，把敏感信息放在gitignored的.env.local中。
Ruby dotenv gem建议的网址是https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use
Symfony 4也已更改为this behavior
当我做nodejs项目的时候，我也使用一个叫做dotenv-flow的npm包来做。

.env文件中包含的密码和API密钥出于安全原因不应进入源代码管理。另外，它们可能会在不同的环境中发生变化（您应该在测试和生产中使用不同的API密钥）
你可以把.env.example.php保存在git中，并根据需要配置的变量更新它，但把值留空，然后在新的安装中把.env.example.php复制到.env，并更新该环境下的值。

添加到.gitignore文件中的文件列表将被Git丢弃，并且不会上传到Git存储库或从Git存储库下载
把.env放在.gitignore中的主要优点。
1).env文件包含有关该项目的敏感信息。您的数据库凭据、您的加密密钥、如果您的应用正在使用任何API，则您可以拥有API密钥/访问令牌等信息可以从.env文件加载，您可能不希望这些凭据对有权访问该项目的每个人都可访问。
2).env文件包含您可能不希望在生产和开发环境中使用的特定设置
例如，在开发环境中，您可以保留APP_DEBUG = true，而在生产环境中，建议使用APP_DEBUG=false。同样，如果您的应用使用任何API（支付网关），则您必须为开发环境使用测试API凭据，为生产环境使用实时凭据（这将导致实际的在线交易），生产环境可以通过.env文件进行管理。

如果.env文件包含敏感信息（如口令或密钥），则务必对这些值保密，避免将其提交到公共或专用资料档案库。这可以通过使用环境变量或单独的配置文件来实现。另一方面，如果.env文件不包含任何敏感信息，它可以安全地提交到存储库，而无需任何顾虑。对于前端开发，通常不需要保护.env文件，因为这些值最终将与客户端代码绑定在一起。但是，评估潜在风险并根据项目的具体要求做出明智的决定始终是一种良好的做法。