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

我在GitHub主持了一个项目。我们正在一个名为metamodel的共享主题分支上开发一组新功能，该分支被推到GitHub上。同时，我们正在主服务器上进行bug修复工作。计划是最终将元模型集成回主模型，此时元模型分支将消失。这两个分支都包含2个目录，我们希望将其内容合并到一个目录中。此时，两个目录在两个分支之间已经存在分歧。此外，在分支机构整合之前，它们将继续分歧更大

---

如果我将每个分支上的两个目录单独合并在一起，那么当我将分支集成在一起时会发生什么？作为一个项目，我们选择通过重定基址的方式来集成分支，以防在这里产生影响。

Git并不真正关心目录，甚至文件名。它关心内容。而且它在合并方面相当智能（它会计算出什么时候只是移动或重命名对象）

所以，基本上，在回答你的问题“当我们将这些分支集成在一起时会发生什么”时，答案是“我不知道”。我还没有看到内容。但我可以告诉你，Git将非常有效地比较内容上的差异/相似之处，并将所有内容很好地结合在一起。Git遇到的任何问题都会显示为合并冲突，您只需逐个解决这些问题

在这种情况下，考虑到您的Git历史记录和更改已经开始变得相当复杂，我会小心地重新设置基址。一个重基也许可以很好地工作，但我已经准备好回滚，以防它变得混乱

---

因为你的分支很分散，走了不同的路线和路径，你最好直接合并，把它们重新组合在一起。这样，您就不会冒着以有害/不可恢复的方式重写历史的风险（请记住，重定基址是重写历史的一种形式）。另外，一个直接的Git合并将产生一个新的commit，它将所有内容组合在一起，这（考虑到已经发生的巨大差异），可能是一个有价值的“岔路口”commit，以防您需要回滚。

重定基址很好，因为它可以清理您的历史记录，但在这样复杂的情况下，我绝对不会这么做

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

我只会专注于合并和清理任何冲突