为贵公司内部使用的项目设置 git 存储库的最佳方法是什么，但您也想开源(但可能修改了历史记录)？
假设 Acme 公司有一个 repo“supercoolproject”。他们想开源它，但他们实际上根本不想要与它相关联的公司名称。他们以其开发人员的名字之一(或群组等)设置了一个 GitHub 帐户，并创建了 repo。他们将其克隆到内部 Acme 服务器。没有任何地方提到“Acme”。
现在问题来了——在任何给定的组织中，都有了解开源并被授权将某些代码公开的开发人员。还有其他人不理解所有的细微差别。当其中之一做出 promise 时，它们可能包括公司名称或其他一些专有信息。或者，他们只是做了一个可怕的提交，可以在内部恢复(不是重写历史——我只是在谈论添加一个“恢复”提交)。但是，您不希望这些专有提交进入开源分支。
因此，您创建了“acme_internal_{dev,qa,production}”分支和一个外部“master”分支(可能还有其他分支)。使它们保持同步的最佳方法是什么？您想要接受对开源存储库的提交。你想推出(大部分)你的内部提交。但也有一些不应该出去的。
merge 内部 -> 外部似乎是一件坏事，因为您无法删除错误的提交。可以在内部分支上重新设置外部分支，但似乎只要你“git rebase -i acme/acme_internal_dev”一次并修改历史(更改提交消息，删除提交等)你就不能再重新设置因为这两个历史是不同的。那么，您最终是否会挑选所有内部提交到公共(public)分支，然后将公共(public)分支 merge 到内部树中？这看起来也很丑陋，因为您最终会在内部重复提交(原始提交，然后是经过精心挑选的进入外部并 merge 回内部的提交)。
为了这个问题的目的，我们假设 Acme 在内部希望避免在其内部分支上重写历史记录(实际上是删除/修改错误的提交)。
最佳答案
您可以采取一些措施来利用您要维护的双重存储库的 DVCS 特性。
首先，永远不要直接向世界公开内部存储库(有一个“外部”分支的想法)。没有“外部分支”这样的东西，只有“外部 - 或'公共(public)' repo ”。
一个可能的设置是让 repo 暴露给世界(外部贡献者可以向其推送或 pull )。
其次，永远不要(从 acme 内部)直接推送到外部存储库:错误很容易犯，而且您无法控制 pull 的速度。也就是说，一旦你推错了东西，即使是迅速的修正也可能来不及。
您需要一个仍在内部管理的中间存储库，以供审查之用。即检查已推送的内容，如果这些新提交没问题，则将它们从外部仓库中 pull 出。
这意味着外部 repo 知道中间 repo (它在其 Remote 中列出)，反之则不然(你不能从内部 repo 错误地推送)。
这使得发布过程更加明确(您必须转到外部存储库服务器并 pull 您想要发布的更改，而不是停留在熟悉的内部环境中，并且有些粗心地推送)
在中间存储库(acme 的开发人员可以在发布前推送以供审查的存储库)中充分利用:
- 预接收 Hook (进行各种控制:如果提交不符合发布标准，则拒绝，然后开发人员可以在他/她自己的 repo 中重写历史)。
同样，重写历史记录是可以接受的，只要它在 acme 的开发人员存储库中得到控制。 - 内容过滤器驱动程序(例如参见 this question )，以便不必为 敏感 文件(如“Something like gitignore but not git ignore ”)在两种存储库之间对不同内容进行版本控制。
关于Git repo : internal and open source external branches，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10884335/