2012-06-04 50 views
4

什么是为您的公司内部使用的项目设置git回购的最佳方式,但是您还希望开源(但具有可能修改的历史记录)?Git回购:内部和开源外部分支机构

比方说,Acme公司有一个回购“supercoolproject”。他们想要开源,但实际上并不需要公司名称。他们使用其开发人员的名字(或团体等)设置了一个GitHub帐户,并创建回购。他们将其克隆到内部的Acme服务器。没有提到“Acme”。

现在出现了这个问题 - 在任何组织中,都有开发人员了解开放源代码并被授权公开推送一些代码。还有其他人不明白所有的细微差别。当其中一个提交时,可能包含公司名称或其他专有信息。或者,他们只是做了一个可以在内部恢复的可怕提交(而不是重写历史记录 - 我只是在谈论添加“还原”提交)。但是,您不希望这些专有提交进入开源分支。因此,你创建了“acme_internal_ {dev,qa,production}”分支和一个外部“master”分支(也许还有其他人)。保持同步的最佳方式是什么?您想接受开源回购上的提交。你想推动(大部分)你的内部提交。但有一些不应该出去。

看来,合并内部 - >外部是一件坏事,因为你不能删除坏的提交。外部分支可以在内部分支上重新分配,但似乎只要一次“修改rebase -i acme/acme_internal_dev”并修改历史记录(更改提交消息,删除提交等),您就不能再分配,因为两个历史分歧。那么,你最终会挑选所有内部提交到公共分支,然后将公共分支合并到内部树中吗?这看起来也很丑陋,因为你最终会在内部重复提交(原始文件,然后选择进入外部并被合并回内部)。

为了这个问题的目的,我们假设Acme内部想要避免在其内部分支上重写历史记录(实际上是删除/修改坏通信)。

+0

最好的解决方案(你想从外部看到的分支,但有一些只在内部可用的提交)是樱桃采摘。对不起,说。 – Greg

回答

1

您可以采取一些措施来利用您要维护的双仓库的DVCS性质。首先,永远不要直接向内部公开一个内部回购(有“外部”分支的想法)。除了“外部分支”,只有“外部 - 或”公共“回购”才有这样的东西。

一个可能的设置是让repo公开给外部世界(外部贡献者可以向其推送或从中拉出)。


其次,从来没有(从ACME内)直接连接到外部回购推:错误是太容易做的,你不完成什么样的速度拉控制。也就是说,一旦你推错了东西,即使是迅速的纠正也许会来得晚。

您需要一个中间回购,内部管理,用于审查目的。即检查推送的内容,如果这些新提交都可以,请将它们从外部回购库中取出。
这意味着外部回购知道中间回购(它有它在遥控器中列出),相反是不正确的(你不能错误地从内部回购推)。
这使得一个更明确的出版过程(你必须去到外部回购服务器和拉要发布的更改,而不是停留在一个熟悉的内部环境,推动有点漫不经心的)


在中间回购(acme的开发人员可以在发布之前推送的那个回购)中使用得很好,其中:

  • 预接收钩子(用于进行各种控制:如果提交不符合发布标准,它被拒绝,然后开发人员可以在他/她自己的回购中重写历史记录)。
    同样,重写历史记录是可以接受的,只要它是acme的开发者回收库中的控制。
  • 内容过滤器驱动程序(例如参见this question),以便不必为敏感文件(如“Something like gitignore but not git ignore”)中的两种回购之间版本不同的内容。
1

的解决方案是让这只能通过那些谁有权推到GitHub的开发者致力于严格控制“externaly可见的”信息库。

来自内部存储库的代码仅通过允许的开发人员将其集成并合并到外部可见存储库中。简而言之,未经许可的开发人员必须通过补丁文件或公开回购请求将其代码提交给允许的开发人员。

是的,这意味着获得许可的人将不得不审查和整合每个补丁。但是,由于您不相信未经许可的开发人员,所以您希望他们无论如何都这样做。