1. 不是真的，不。正如 nbering 所说，如果您想分享它，很难将其从 git 历史记录中删除。Git 也不是真的要保存这种信息。
2. 不多。密码只加密密钥，所以没有加密密钥，他们真的什么也做不了。
3. 很多。他们可以创建一个包含恶意软件的应用程序版本，并将其作为您的应用程序传递。但是，如果无法访问您的应用商店帐户，他们可能无法直接发布。这仍然允许他们以其他方式分发它，例如。通过不同的应用商店或使用网络。如果他们确实获得了对您的应用商店帐户的访问权限，他们可以将他们的恶意软件版本作为更新发布，而用户将无法知道。
4. 是和不是。如果您使用手动构建，那么您可以将文件添加到 gitignore 并以其他方式分发。如果您使用自主构建，大多数 git 站点都支持存储机密的特殊功能。

为什么不？

这都是风险问题。我反对的主要论点是，如果您想与不应该拥有密码的人共享该存储库，那么很难从 git 历史记录中删除密码。您需要重写所有历史记录。因此，您必须重写所有提交，或者压缩以丢失包含密码的历史记录。而且您可能不会记得这样做，因此将它们排除在外是最安全的。

避免提交秘密

为了避免在 git 中存储秘密，我通常将秘密文件添加到 .gitignore。由于有人可能需要知道现在丢失的文件中的内容，因此请留下gradle.properties.example文件之类的内容，将编辑字段设置为“CHANGEME”或类似的内容，以便使用该文件的任何人都知道如何创建gradle.properties.

如果可能，请从环境变量中替换，这样您就不需要使用 .example 文件。我个人推荐一个像direnv这样的工具，它允许你创建一个被 git 忽略的 .envrc 文件，它可以用来在每个项目的基础上设置环境变量。当您进入目录时，它会自动从终端加载环境变量。但是，这并不总是适用于图形工具，因为它们的环境变量将从启动它们的环境中获取。

一些图形 IDE 确实支持“目标”或“工作区”之类的概念，它们理解某些配置选项是在签入源代码控制的文件中配置的，而其他配置选项则特定于您计算机上的文件。

有什么风险？

如果有人掌握了您的签名密钥和密码，他们可能会签署您的应用程序的恶意副本。

如果他们设法将此副本提交到应用商店，您的用户可能会自动收到恶意副本，而不会通知它已更改。他们的设备会信任它，因为它是由您的密钥签名的。

即使没有应用商店提交，他们也可以签署应用程序的副本并将其侧加载到已安装应用程序的设备上，该设备仍会信任它，因为它是由相同的密钥签名的。