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