为公司内部使用的项目设置git仓库的最佳方法是什么,但您也想要开源(但可能具有修改过的历史记录)？

让我们说Acme公司有一个回购“supercoolproject”.他们想要开源它,但他们实际上并不想要与之相关的公司名称.他们在其开发人员名称(或组等)下创建了一个GitHub帐户,并创建了回购.他们将其克隆到内部Acme服务器.没有提到“Acme”.

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

因此,您创建“acme_internal_ {dev,qa,production}”分支和外部“主”分支(可能还有其他分支).保持这些同步的最佳方法是什么？您想接受开源回购的提交.并且您希望推动(大部分)内部提交.但也有一些不应该出去.

似乎合并内部 – >外部是一件坏事,因为你无法删除糟糕的提交.在内部分支上重新分配外部分支可以完成,但似乎只要你“git rebase -i acme / acme_internal_dev”一次并修改历史记录(更改提交消息,删除提交等),就不能再进行rebase了,因为这两个历史不同.那么,您是否最终将所有内部提交挑选出公共分支,然后将公共分支合并到内部树中？这看起来很难看,因为你最终会在内部重复提交(原始的,然后是樱桃挑选的一个进入外部并被合并回内部).

出于这个问题的目的,让我们假设内部Acme想要避免在其内部分支上重写历史记录(实际上删除/修改不良提交).

最佳答案 您可以采取一些措施来利用您想要维护的双重仓库的DVCS特性.

首先,永远不要将内部回购直接暴露给世界(想要拥有“外部”分支).没有“外部分支”这样的东西,只有“外部 – 或’公共’回购”.

可能的设置是让repo暴露给世界(外部贡献者可以推送到或从中拉出).

其次,永远不要(从极致内部)直接推送到外部回购：错误太容易完成,而且你无法控制拉动的速度.也就是说,一旦你推错了东西,即使是迅速的纠正也可能会迟到.

您需要一个仍在内部管理的中间回购,以供审核.即检查已推送的内容,如果这些新提交正常,则从外部仓库中取出它们.
这意味着外部回购知道中间回购(它已在其遥控器中列出),反之则不然(你不能错误地从内部回购中推).
这样可以实现更明确的发布过程(您必须转到外部repo服务器并提取您要发布的更改,而不是保持熟悉的内部环境,并且稍微不加思索地推送)

充分利用中间回购(acme的开发人员可以在发布之前进行审查的那个),：

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