为公司内部使用的项目设置git仓库的最佳方法是什么，但您也想要开源（但可能具有修改过的历史记录）？
让我们说Acme公司有一个回购“supercoolproject”。他们想要开源它，但他们实际上并不想要与之相关的公司名称。他们在其开发人员名称（或组等）下创建了一个GitHub帐户，并创建了回购。他们将其克隆到内部Acme服务器。没有提到“Acme”。
现在出现了问题 - 在任何给定的组织中，都有开发人员了解开源并被授权将一些代码公开。还有其他人不了解所有的细微差别。当其中一个提交时，它们可能包含公司名称或其他一些专有信息。或者，他们只是做了一个可以在内部恢复的可怕提交（不是重写历史 - 我只是在谈论添加“恢复”提交）。但是，您不希望这些专有提交进入开源分支。
因此，您创建“acme_internal_ {dev，qa，production}”分支和外部“主”分支（可能还有其他分支）。保持这些同步的最佳方法是什么？您想接受开源回购的提交。并且您希望推动（大部分）内部提交。但也有一些不应该出去。
似乎合并内部 - ＆gt;外部是一件坏事，因为你无法删除糟糕的提交。在内部分支上重新分配外部分支可以完成，但似乎只要你“git rebase -i acme / acme_internal_dev”一次并修改历史记录（更改提交消息，删除提交等），就不能再进行rebase了，因为这两个历史不同。那么，您是否最终将所有内部提交挑选出公共分支，然后将公共分支合并到内部树中？这看起来很难看，因为你最终会在内部重复提交（原始的，然后是樱桃挑选的一个进入外部并被合并回内部）。
出于这个问题的目的，我们假设内部Acme希望避免在其内部分支上重写历史记录（实际上删除/修改不良提交）。
答案 0 :(得分：1)
您可以采取一些措施来利用您想要维护的双重仓库的DVCS特性。
首先，永远不要将内部回购直接暴露给世界（想要拥有“外部”分支）。没有“外部分支”这样的东西，只有“外部 - 或'公共'回购”。
可能的设置是让repo暴露给世界（外部贡献者可以推送或拉出）。
其次，永远不要（从极致内部）直接推送到外部回购：错误太容易完成，而且你无法控制拉动的速度。也就是说，一旦你推错了东西，即使是迅速的纠正也可能会迟到。
您需要一个仍在内部管理的中间回购用于审核目的。即检查已推送的内容，如果这些新提交正常，则从外部仓库中取出它们
这意味着外部回购知道中间回购（它已在其遥控器中列出），反之则不然（你不能错误地从内部回购中推）。
这样可以实现更明确的发布过程（您必须转到外部仓库服务器并提取您要发布的更改，而不是保持熟悉的内部环境，并且稍微不加思索地推动）
在中间回购（acme的开发人员可以在发布前推送审查的那个）上充分利用：
答案 1 :(得分：1)
解决方案是拥有一个严格控制的“外部可见”存储库，只有那些有权推送到github的开发人员才能提交。
来自内部存储库的代码仅通过由允许的开发人员集成和合并而使其成为外部可见的存储库。简而言之，非允许的开发人员必须通过补丁文件或针对公共仓库的请求向允许的开发人员提交他们的代码。
是的，这意味着获得许可的人必须审核并整合每个补丁。但是，既然你不信任非允许的开发人员，那么无论如何你都希望他们这样做。