Question

我在github上有一些项目，我以任何人都可以部署的方式发布了这些项目。我有如下配置文件：

my-project
├── config.yaml
├── dev.yaml

除了要添加两个应该是私有的文件之外，我想从相同的代码库进行部署。文件将如下所示：

my-project
├── config.yaml
├── dev.yaml
├── confidential-stuff.yaml
├── more-confidential-stuff.yaml

这意味着公共项目中的文件是严格的子集。

我们如何处理此类私有配置文件？用私人叉子？如果是这样，您如何确保它们同步？我的目标是减少重复，即尽可能使用一个代码库。

编辑：我可以将文件放在.gitignore中，但它们将不再受版本控制，因此在部署管道中不可见。

Answer 1

我通常的建议是，应使用模板之类的技术代替本地配置文件，将本地（或私有）配置信息置于源代码控制之外。

此处的不同之处在于，您希望排除整个配置文件的存在，同时仍希望在源代码管理中使用它。

您说的让它们进入源代码管理的原因是对构建管道的可见性。还有其他方法可以使文件可用于构建管道，如果这是对文件进行源代码控制的 only 原因，那么我建议改用其中一种机制。详细信息取决于您的构建工具，但是您可以确定是否可以授予构建过程访问共享文件夹的权限，并在需要时复制文件。

另一方面，如果您需要同步文件的历史版本，那将是一个更加困难的问题。也就是说，也许在第5版中，所需的内容已更改，但是如果签出/构建版本4，您仍然需要构建过程以使用旧内容。

在这种情况下，您可以考虑创建一个分支来保存您的构建版本（包括私有配置文件）。不这样做有两个很好的理由：

（！）通常，拥有不同的分支来存储不同的内容集会导致问题。来自诸如TFVC之类的工具的人有时会采用一种普遍做法，即“为此项目创建一个分支，然后为该项目创建另一个分支”，这会带来麻烦。或者人们希望分支代表整体内容的一部分，但是当他们将其合并回来时，他们会感到惊讶，因为他们的一堆文件被从母版中删除了。等等...

在这种情况下，“奇数”分支是其他内容的超集，因此许多通常的问题将不适用，但是如果没有充分的理由，则仍然不考虑这种做法。

（2）您必须小心，永远不要从“私有”分支泄漏信息；有很多潜在的错误方法，显然不要从该分支合并到任何其他分支，等等。

如何保持分支的私密性？好吧，如果远程的托管软件支持分支级权限，则可能会有所帮助。如果没有，则永远不要将私有分支推送到公共远程站点；相反，也许您在构建过程中还有第二个遥控器。

因此，第一次进行构建时，请签出发行版本，创建“私有构建”分支，在该分支上添加配置文件，然后退出。然后，每个后续发行版本会将发行版本合并到“私有构建”分支，根据需要（在合并期间或在合并之前的提交中）编辑私有配置文件。

Answer 2

考虑类似Shopify's EJson库的内容。它允许您使用非对称加密将生产配置存储在存储库中，这意味着它与使用的代码一起进行了版本控制。

您可以使用它来进行不同的配置（即dev / test / production），将dev / test凭证以纯文本格式存储，以便您的开发人员可以运行该应用程序，但可以将加密的生产凭证存储为仅生产环境可以解密它们。

我们如何处理公共存储库中的私有配置文件？

2 个答案: