如何在git中合并两个不同目录层次结构的分支？
我开始在Web应用程序项目中使用Maven，以便更改目录层次结构。 我为Maven集成创build了一个新的分支。 现在我有两个分支，一个是旧的目录层次结构，一个是Maven目录层次结构。 两个分支都有新的提交（错误修正和新function）。
我想摆脱旧的分支，并将其更改合并到Maven分支。 Git合并提供了无数的冲突，感觉不可能解决。 我相信这是因为文件path已经改变。
什么是最好的方法来进行合并？
尝试将merge.renameLimit设置为高度合并。 git会尝试检测重命名，但只有当文件数量低于此限制时，才需要O（n ^ 2）处理时间：
git config merge.renameLimit 999999
那么当完成时：
git config --unset merge.renameLimit
博客文章“ Confluence，git，rename，merge oh my … ”增加了一些有趣的信息，说明了Robie的回答 （upvoted）：
当尝试检测重命名时，git使用以下命令区分精确和不精确的重命名 ：
- 前者是重命名而不改变文件的内容
- 后者是重命名，可能包括对文件内容的更改（例如重命名/移动Java类）。
这个区别是重要的，因为用于检测精确重命名的algorithm是线性的并且将始终执行，而不精确重命名检测的algorithm是二次的（
O(n^2)），并且如果文件数目改变超过git，则git不会尝试执行此操作一定的阈值（默认为1000）。如果未明确设置，则
merge.renameLimit默认为1000个文件，如果设置，则使用diff.renameLimit的值。
diff.renameLimit会影响git diff，git show和git log而merge.renameLimit适用于合并尝试（git merge，git cherry-pick）。改变
merge.renameLimit是一个好主意，而不是改变diff.renameLimit这样git不会在常见操作中寻找重命名，例如查看git diff输出。为了显示重命名，像
git show或git log这样的命令可以用于打开重命名检测的-M选项。
Linus提到 ：
是的，对于内核，我有
[diff] renamelimit=0
完全禁用该限制，因为默认限制的确非常低。 Git在重命名检测方面非常出色。
然而，低默认值的原因并不是因为它不够灵活 – 这是因为它最终会使用大量的内存（如果内存不足，交换将意味着它从“相当活泼”到“慢糖蜜” – 但它仍然不会受到CPU限制，这只是疯狂的分页）。
