我在GitHub上有一个项目。我们正在一个名为metamodel的共享主题分支上开发一组新功能，这些功能推送到GitHub。与此同时，我们正在主人身上进行持续的错误修复工作。计划是最终将元模型重新集成到master中，此时元模型分支将消失。这两个分支都包含2个目录，其内容我们要合并到1个单目录中。此时，2个目录已经在2个分支之间发散。此外，他们将继续分歧，直到分支整合。
如果我将每个分支上的2个目录合并在一起，那么当我将分支集成在一起时会发生什么？作为一个项目，我们选择通过变基来整合分支机构，如果这里有分支的话。
答案 0 :(得分：1)
Git并不关心目录，甚至文件名。它关心内容。它在合并方面相当聪明（只要简单地移动或重命名就会弄明白）。
所以，基本上，在回答你的问题“我们将这些分支整合在一起会发生什么”时，答案是 - “我不知道”。我还没有看到内容。但我可以告诉你，Git会相当有效地比较内容中的差异/相似之处，并将所有内容很好地结合在一起。 Git被卡住的任何东西都会显示为合并冲突，你只需要根据具体情况解决这些问题。
在这种情况下，考虑到你的Git历史和变化开始变得相当复杂，我会小心变基础。一个rebase可能工作正常，但我会准备好回滚，以防它变得混乱。
由于您的分支机构强烈分散并且走了不同的路线和路径，您可能最好进行直接合并以将它们重新组合在一起。这样你就不会冒险以有害/不可恢复的方式重写历史（请记住，变基是重写历史的形式）。另外，一个直接的Git合并将产生一个新的提交，所有组合在一起，（考虑到已发生的巨大差异），可能是一个有价值的“fork-in-the-road”提交，以防万一你需要回滚
答案 1 :(得分：0)
重新定位很好，因为它可以清理你的历史，但我绝对不会在如此复杂的情况下这样做。
基本上，如果您曾经将分支推送到远程，那么在大多数情况下，您都希望避免在该分支上使用rebase。在分支机构上进行一些本地更改以改善历史记录是很好的，但在此之后，以及推送到远程，只需使用合并。
我只关注合并并清理任何冲突。