两个 repo 的情况下（一个开源一个闭源）如何更简单的管理隐私文件？

[SharkIng]

不知道有没有人这么做过，就是公司级别开源程序中，公司想同时维护一个 public repo 和一个 private repo：

• private 中带有一些 production cofigs 文件和 keys，密码等文件（统称 secrets ）
• public 中包含必须的相对应文件的 .stub 示例
• 其他程序相关文件完全相同

那么在这种情况下如何更简单的维护这两个 repos 呢？

现在能想到的办法：

• 两个文件夹，对应两个 repos，在修改后互相 copy 然后 push，或者使用 pre-commit/post-commit 自动 cp
  • 问题，多余的本地存储空间
  • 不方便管理，如果 cp 报错的话就不行了
• 两个不同的 .gitignore 文件对应不同的 remote
  • Google 了下好像这样不可行
• 同理办法一，但是使用 symlink
  • 没有实验过 symlink 的文件在 repo 中的话如果 commit 和 push 到底效果是什么样的？

还有没有什么别的办法？

[Trim21]

submodule ？

[msg7086]

程序文件做成 submodule，然后 private 和 public 里存放必须的文件，然后引入 submodule。

其实也很麻烦的。建议还是不要把秘密放在 repo 中。

[stcheng]

提供一个思路，在 public 和 private 分别有两个一样的 repository，private 的 repo 下的其中几个 commit 是 secret files 和 internal features。每次 public 和 private 的 pull request 分开 review，internal 的所有 commit 都 rebase 在 public 的 commit 上。每次 public 有更新，internal 就做一个 rebase update 然后再 force push 到 internal 的 branch 上。

[SharkIng]

@Trim21
@msg7086 其实有考虑到 submodule 但是总体觉得可行，但的确麻烦，submodule 也不是这么用的 :P
不过实在不行的情况下可能会这么处理


@stcheng 这个思路我研究下，大体情况是我们不想有任何 force push 的情况，另外就是非必须情况下尽量不用 rebase

[stcheng]

一开始我也是考虑用 submodule 的，但是问题在于很多时候有超出 secret files 的 change，比如同一个文件 public 和 internal 会有区别，这样就无法使用 submodule 区分开来。我们现在在生产环境中这样做基本没有碰到太大的问题，相对来说 public 的 commit 更容易 maintain。

[xiaket]

即使是 private repo 也不应该用来放 secret.

[SharkIng]

@stcheng #5 对，是的，如果同一个文件需要不太一样的内容就没办法了。所以您现在是怎么处理 Public 和 Private 的？


@xiaket #6 也不完全是 secret，这个只是一个直观的说法。有很多情况下很多东西是不想开源的，但是又会备用到，不一定局限于密码和密钥，还有可能是部分内部的 method 或者配置文件等。

[networm]

可以考虑将密码、密钥、配置文件等放在构建流程里，这样仓库可以不用区分公开与私有。

[stcheng]

private 的 repository 像是一个 patching repository。大部分内容都在 public 开发和 review。但是需要专门对 private 的 repository 进行 rebase，没有 conflicts 的情况下再 force push，保证 private repository 的最顶端都是 up-to-date 的 patch commits sit on top of the current master of public branch。secrets file 基本上都是 Ansible secrets，不存在任何 repository 里面。private repository 存放无法开源的 feature 和 internal 的 system/lab environment setup。

因为一般来说大部分还是开源的，所以 maintain private repository 的 work load 不是特别重。

[SharkIng]

@stcheng #9 好的了解了，谢谢，我们试试