6

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

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

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

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

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

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

4

2 回答 2

3

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

首先，永远不要直接向世界公开内部仓库（有一个“外部”分支的想法）。没有比“外部分支”这样的东西，只有“外部——或‘公共’回购”。

一种可能的设置是让 repo 向世界公开（外部贡献者可以向其推送或拉取）。

其次，永远不要（从 acme 内部）直接推送到那个外部仓库：错误太容易犯了，而且你无法控制拉取的速度。即，一旦你推错了东西，即使是快速的纠正也可能来晚了。

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

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

  • pre-receive hooks（进行各种控制：如果提交不符合发布标准，则会被拒绝，然后开发人员可以在他/她自己的 repo 中重写历史记录）。
    同样，重写历史是可以接受的，只要它是在 acme 的开发人员存储库中的控制。
  • 内容过滤器驱动程序（例如参见这个问题），以便不必在敏感文件的两种存储库之间对不同的内容进行版本化（如“ Something like gitignore but not git ignore ”）。
于 2012-06-04T17:06:43.420 回答
1

解决方案是拥有一个严格控制的“外部可见”存储库，该存储库只能由有权推送到 github 的开发人员提交。

来自内部存储库的代码只有通过被允许的开发人员集成和合并才能进入外部可见的存储库。简而言之，未经许可的开发人员必须通过补丁文件或针对公共存储库的拉取请求将其代码提交给允许的开发人员。

是的，这意味着获得许可的人必须审查和集成每个补丁。但是，由于您不信任未经许可的开发人员，因此您希望他们无论如何都这样做。

于 2012-06-04T17:29:43.310 回答