.env 应不应该放到 git 中？

[FaiChou]

Gatsby.js Link

Please note that you shouldn’t commit .env.* files to your source control and rather use options given by your Continuous Deployment (CD) provider.

在 Gatsby.js 文档中提到， .env.* 不应该提交到 git 中，但是 .env.* 里的变量不都是给项目用的吗？最终编译后可以在代码中找到对应的值，所以对用户而言，这些变量都是 public 的。

所以我觉得 .env.* 可以放到 git 中，即使是一个开源项目。

[littleylv]

不应该传.env
要传.env.example
然后 example 里注意不要写正式的，用通用字符代替，比如
password=YOUR_PASSWORD （而不是 123abc ）

[FaiChou]

@tabris17 #18 嗯，后端的就涉及 private_key 了，相对来说，前端用的都是些 public_key 。所以前端 public_key 也无所谓被 public 出去。

[momocraft]

想做就做吧 我看别人花时间说服你也挺累的
自己的东西自己负责而已

[FaiChou]

@momocraft #23 当然不可能这么做 ^_^，也不需要被说服。 想了解下前端 .env 放 ignore 中的其他理由。

[offline]

.env.example 放注释

.env.default 放默认，这个应

[offline]

.env.example 放实例

下面两个都应该忽略
.env.default 放默认，这个应该在自己的服务器上生成，不提交 git
.env 放本地私有

[hfpp2012]

肯定不放 git 中呀

[kasper4649]

[x] .env
[✓] .env.example

[ben1024]

不放 .env, 进行线上编译才是正确

[BenX]

最佳实践来看，可以放一个样板同步上到 repo，例如 .env.example
同步还要在 readme 中描述解释清楚里面需要有哪些变量。

自己本地的 .env 就不要放到 repo


PS，遇到过啃爹的一个项目就是 .env 没放，readme 也不说和写有哪些变量。
要跑起来要不能抓到人，要不就只有自己看代码找去了

[jun0205]

.env.example 需要

[redam]

前端可以有.env.local，local 的就 ignore

[polun]

如果放 git 里，就不需要 .env 了，直接静态变量不更好吗。

[ratatata]

.env 不能放，但是应该放一个 .env.example，列出需要配置的变量

[MeteorCat]

example.env ，之后忽略文件.env

[Chingim]

不要教条主义，含敏感信息的就不要放，不含的无所谓，含有构建项目需要的信息(比如各种环境下的 API 地址)那就必须放到项目里

[Chingim]

因为不同的项目从 env 文件中读取的信息都不一样，何必纠结。

[Kobayashi]

不放。会放一个模板 .env.example

[msg7086]

.env 从名字上来说就是对每个环境的分别配置。
既然是对每个环境有效，当然不应该放在「对所有环境有效」的 Git 中。
这和前端后端没有关系，这是.env 本身的身份决定的。
是否 Public 和是否包含.env 没有直接关系。你源代码都是 Public 的，为什么变量不放在源码的配置文件里？

[RRRSSS]

一般开源项目里都这么干：

.env.simple 文件放 git，然后里面用变量表示，比如：

DB_PASSWORD = ${your_password}

然后 .env 加入 .gitignore

最后 README 里加上，要用户 `cp .env.simple .env`，这样可以控制每个人是不同的配置，简单明了。