如何使用Git逐步合并大型分支？

Question

概述：

我们有一个相当大的存储库（约10M LOC），需要使用Git进行处理。我们需要在开发分支之间执行复杂的合并操作，这些分支太大了，无法一次性完成。然而，Git似乎不支持这种需求。在你提交了两个分支之间的“合并”后，Git会认为已经解决了那些分支上的所有文件。有什么最好的方法来逐步处理庞大的合并过程呢？

背景：

我们想要将工作分散到多个提交和多个开发人员中进行。代码库正在通过独立的CVS存储库由不同的团队进行积极更新。因此他们的分支上的工作只是tarball代码快照，没有提交历史记录。

我们计划将这些快照存储在不同的分支上，如下所示：

Master: Rel 1 -> Rel 2

Site B : \ -> Rel 1.1

我们的团队打算做类似Site B的工作，但Site B可能会继续并行工作。因此，我们将保留“Master”和“Site B”分支以备将来导入时使用。我们将为我们的工作创建一个新的开发分支。第一步是将“Rel 1”和“Rel 2”之间的差异合并到“Rel 1.1”工作中。基本上是“Master”和“Site B”分支之间的三方合并。

执行单个合并文件操作似乎很笨拙，并且不会保留任何实际历史记录。使用cherry-picks也类似。

有什么建议吗？

- agentchuck

---

使用Git时应该按照正确的方式使用：使用适当的存储库和适当的历史记录。然后合并就不会引起太多麻烦（甚至可以在合并过程中继续工作）。 - knittl

@knittl：我知道这不是Git合并的标准用例。但不幸的是，我们有多个开发团队不在同一个代码库中工作。我们希望能够更像Perforce集成一样，在不同变更列表中使用文件子集之间的分支进行集成。完成一个集成不会关闭P4正确计算剩余文件的集成/合并的可能性。Git似乎不允许这种选项。 - agentchuck

是的，因为Git总是在完整的树上工作。请注意，您不需要合并在分支之间未更改或仅在单个分支中更改的文件。您是否真的尝试过您的方法？考虑到提交之间正确的祖先信息，合并应该不会太糟糕。但最终，当开发人员不使用此Git存储库时，他们如何获取合并的代码？ - knittl

@knittl：本地开发人员将来会使用这个Git代码库。我们正在将基础产品线的代码合并到更具体的产品线中，并且不会将我们的代码增量推回到基础线。虽然有点麻烦，但在大公司工作就是这样有趣。 - agentchuck

@agentchuck，Git支持“子树合并”（http://git-scm.com/book/en/Git-Tools-Subtree-Merging），它允许您仅使用另一个*完整*项目的历史记录更新项目树（由目录表示）的一部分。不知道这与您提到的Perforce集成相比如何，但也许这可以帮助您的情况。 - kostix

Answer 1

这是一个旧问题，但由于它刚在我进行的相关谷歌搜索中出现并且没有答案，所以我现在回答它。

git imerge工具通过支持增量协作合并来处理该问题。imerge文档指向了一篇很棒的博客文章，介绍如何使用它。

- Craig Peterein