这是一个有趣的问题，有几个方面应该被分解。

你问的第一个问题是“这有多大风险？” 答案是“非常”。将这些凭据暴露在您无法控制和管理的第 3 方服务上，就会增加风险。您的凭据可能会以多种方式暴露：服务泄露、服务帐户受损、服务授权失败、网络窃听（如果 SSL/TLS 不用于提供代码）、您授予错误的人访问权限等。

基本上，考虑那些暴露的凭据。

听起来很可怕，对吧？也许不是……现在你必须问“我对这种风险感到满意吗？” 如果您有其他缓解措施，那么您可能会接受它。如果您限制（可能通过 IP 白名单）可以使用这些凭据的位置，那么这些凭据对于窃取的用处就变得不那么有用了。该服务的价值也可能极低，增加额外的安全性在财务上没有意义。如果从妥协中恢复的成本是 10 美元，而增加额外的安全性将花费 1,000,000 美元，那么您将承担风险。（也就是说，如果您已向您的用户承诺保护他们或他们的信息，那么您有道德义务尝试履行该承诺，无论成本如何。）

一些额外的想法：

“我正在为我的公司工作的项目” - 你代表你工作的公司这样做，他们可能有政策或可接受的做法。如果是这样的话，那些应该优先于你喜欢的东西。您制造的风险会影响您的公司及其声誉，公司可以做出最终决定。

Lucas Kauffman 提出了一个好的方法。我不能说它是否适合您，但要点是找到适合您的部署过程并将风险降低到舒适水平的缓解措施。

我这样做就像我从不同位置处理存储在 Github 上的项目一样。但是，当我的代码进入验收或生产阶段时，密码会随机更改。因此，对于测试/开发，我并不真正关心我的数据库凭据是否存在，因为它们仅在我的开发机器上有效，并且其中没有任何数据是机密的。

无论您的（放松的？）安全需求级别是否可以将密码存储在存储库中，绝对没有必要这样做。

我刚刚在 php 脚本中使用的数据库密码遇到了同样的问题，我的答案是编写一个简单的 php 脚本来自动生成随机密码。这个想法是在第一次下载源代码之后运行一次密码生成器，以生成本地密码。这些永远不应该被推送到存储库；当代码被下载到别处（由合作者或生产服务器上）时，生成器必须再次在本地运行一次以获取一组不同的密码。

如果您懒得自己实现它，只需使用我的代码（目前假设数据库和 php 解释器在同一台服务器上运行）：https ://bitbucket.org/steinb/nopassword

以纯文本形式将密码存储在任何地方总是有风险的。现在我不确定这在 php 中是否可行，但我知道在 .NET 中可以加密配置文件。