代码之家 › 专栏 › 技术社区 › Jab

在远程存储库中创建多个头

mercurial

4

Jab · 技术社区 · 16 年前

我们目前有一个非常大的存储库,其中包含多个相关的项目。它们共享很多代码,但是项目的各个部分由不同的团队(3个团队)部署,独立于代码库的其他部分。所以每个团队都在研究并发的大型特性。

所以我最初的想法是在这些情况下使用命名分支。Team1从Hg中的默认分支生成Feature1分支。现在,问题来了。如果团队将处于当前/半状态的分支推送到存储库中。这将在核心回购中产生第二个头部。

我最初的反应是“不!”好像是个坏主意。在我们的存储库中处理多个头部听起来很糟糕,但是有一些优点。。。

首先,团队希望在开发周期(几个月)内建立持续集成来构建这个分支。只有CI能够从回购中提取此分支时,此操作才会起作用。这是我们现在使用SVN所做的,复制CI构建并更改分支。容易的。

其次,它使任何团队成员都更容易跳到分支上并开始工作。如果不推送到核心回购,他们将不得不从该团队的开发人员那里得到一个包含变更集信息的推送。也可能由于硬件故障而丢失本地提交。如果是由一个遵循“完成前不要推”方法的开发人员创建的分支,那么这种可能性会增加很多。

有没有更好的方法来处理我可能错过的这种情况?我只是想先听听老兵的意见,然后再继续制定战略。

对于bug修复,我们喜欢Mercurial的一般工作流,匿名分支只包含1-2个提交。对于这些情况,简单性是非常好的。

顺便说一下,我读过 this

2 回复 | 直到 15 年前

1

Ry4an Brase 16 年前

你肯定在想这个问题,听起来你走的是一条好路。我是一个分支克隆人,但命名分支已经走过了很长的路。

有一个中心ish repo,所有命名的分支都被推送到其中,这便于控制和备份。只处理分支X的团队可以通过执行以下操作轻松创建自己的分支X回购 hg clone -r X central-ish repo .

hgwebdir.cgi

2

1

Rudi 16 年前

我将通过这些项目之间的耦合(以及其中交换了多少补丁)来决定是否将这三个项目放入一个存储库。它们越独立,一次回购的优势就越小(除了备份和管理)。有一些不同类型的设置:

如您所示,一个存储库,一个分支用于共享代码,每个项目一个分支。当项目本身是通过分叉共享代码库生成的时,在合并回公共代码库(cherry picking)时必须小心。当每个项目分支内部对公共分支的更新被生成为公共分支的直接祖先,并被合并到项目分支中时,很有可能它们也被合并回公共分支中。但是,如果对common的更改是在项目分支之上开发的,则需要重新合并。我没有这种设置的经验,但我担心合并会有问题。
一个回购用于共享,每个项目一个回购,共享回购的代码用作内部版本。当共享代码库没有大的常规更改时,我会选择这种设置。

很抱歉,我没有给出具体的答案,但“正确的事情”(TM)在很大程度上取决于当地的细节。