Git repo：内部和开源外部分支

Question

为公司内部使用的项目设置 git repo 的最佳方法是什么，但您也想开源（但可能会修改历史）？

假设 Acme 公司有一个回购“supercoolproject”。他们想要开源它，但他们实际上根本不想要与它相关联的公司名称。他们以开发人员的名字（或组等）设置了一个 GitHub 帐户，并创建了存储库。他们将其克隆到内部 Acme 服务器。没有提到“Acme”。

现在问题来了——在任何给定的组织中，都有了解开源并被授权将一些代码公开的开发人员。还有其他人不了解所有细微差别。当其中之一进行提交时，可能会包含公司名称或其他一些专有信息。或者，他们只是做了一个可以在内部恢复的可怕的提交（不是重写历史——我只是在谈论添加一个“恢复”提交）。但是，您不希望这些专有提交进入开源分支。

因此，您创建了“acme_internal_{dev,qa,production}”分支和一个外部“master”分支（也可能是其他分支）。保持这些同步的最佳方法是什么？您希望接受对开源存储库的提交。并且您想推送（大部分）您的内部提交。但是有一些是不应该出去的。

似乎合并 internal -> external 是一件坏事，因为您无法删除错误的提交。可以在内部分支上重新设置外部分支，但似乎一旦您“git rebase -i acme/acme_internal_dev”一次并修改历史记录（更改提交消息、删除提交等），您就不能再重新设置基准，因为两个历史背道而驰。那么，您是否最终将所有内部提交都挑选到公共分支，然后将公共分支合并到内部树中？这看起来也很丑陋，因为您最终会在内部重复提交（原始提交，然后是精心挑选的进入外部并合并回内部的提交）。

出于这个问题的目的，让我们假设 Acme 在内部希望避免在其内部分支上重写历史记录（实际上是删除/修改错误提交）。

Answer 1

您可以采取一些措施来利用您想要维护的双重存储库的 DVCS 性质。

首先，永远不要直接向世界公开内部存储库（具有“外部”分支的想法）。不存在“外部分支”这样的东西，只有“外部——或‘公共’存储库”。

一种可能的设置是将存储库公开给全世界（外部贡献者可以向其推送或从中提取）。

其次，永远不要（从 acme 内部）直接推送到外部存储库：很容易犯错误，而且您无法控制拉取的速度。也就是说，一旦你推出了错误的东西，即使是迅速的纠正也可能会为时已晚。

您需要一个仍然在内部管理的中间存储库，用于审核目的。即检查已推送的内容，如果这些新提交正常，则从外部存储库中提取它们。
这意味着外部存储库知道中间存储库（它已将其列在其遥控器中），反之则不然（您不能从内部存储库错误地推送）。
这使得发布过程更加明确（您必须转到外部存储库服务器并拉取您想要发布的更改，而不是留在熟悉的内部环境中，并有些不小心地推送）

在中间存储库（acme 的开发人员可以在发布前进行审查的存储库）上充分利用：

• 预接收挂钩（进行各种控制：如果提交不符合发布标准，则会被拒绝，然后开发人员可以在他/她自己的存储库中重写历史记录）。
  再次强调，重写历史是可以接受的，只要它在 acme 的开发人员存储库内进行控制即可。
• 内容过滤器驱动程序（例如，请参阅此问题），以便不必在敏感文件的两种存储库之间对不同内容进行版本控制（如“类似于 gitignore 但不是 gitignore 的东西”）。