在单独的git分支上合并2个目录的内容并稍后集成分支

时间:2012-06-04 21:36:53

标签: git

我在GitHub上有一个项目。我们正在一个名为metamodel的共享主题分支上开发一组新功能,这些功能推送到GitHub。与此同时,我们正在主人身上进行持续的错误修复工作。计划是最终将元模型重新集成到master中,此时元模型分支将消失。这两个分支都包含2个目录,其内容我们要合并到1个单目录中。此时,2个目录已经在2个分支之间发散。此外,他们将继续分歧,直到分支整合。

如果我将每个分支上的2个目录合并在一起,那么当我将分支集成在一起时会发生什么?作为一个项目,我们选择通过变基来整合分支机构,如果这里有分支的话。

2 个答案:

答案 0 :(得分:1)

Git并不关心目录,甚至文件名。它关心内容。它在合并方面相当聪明(只要简单地移动或重命名就会弄明白)。

所以,基本上,在回答你的问题“我们将这些分支整合在一起会发生什么”时,答案是 - “我不知道”。我还没有看到内容。但我可以告诉你,Git会相当有效地比较内容中的差异/相似之处,并将所有内容很好地结合在一起。 Git被卡住的任何东西都会显示为合并冲突,你只需要根据具体情况解决这些问题。

在这种情况下,考虑到你的Git历史和变化开始变得相当复杂,我会小心变基础。一个rebase可能工作正常,但我会准备好回滚,以防它变得混乱。

由于您的分支机构强烈分散并且走了不同的路线和路径,您可能最好进行直接合并以将它们重新组合在一起。这样你就不会冒险以有害/不可恢复的方式重写历史(请记住,变基是重写历史的形式)。另外,一个直接的Git合并将产生一个新的提交,所有组合在一起,(考虑到已发生的巨大差异),可能是一个有价值的“fork-in-the-road”提交,以防万一你需要回滚

答案 1 :(得分:0)

重新定位很好,因为它可以清理你的历史,但我绝对不会在如此复杂的情况下这样做。

基本上,如果您曾经将分支推送到远程,那么在大多数情况下,您都希望避免在该分支上使用rebase。在分支机构上进行一些本地更改以改善历史记录是很好的,但在此之后,以及推送到远程,只需使用合并。

我只关注合并并清理任何冲突。