git合并具有不同目录结构的两个分支

我有一个要素分支和一个主分支，我想将主分支合并到要素分支。问题是：这两个分支的目录结构不同

---

功能分支的目录结构如下所示：

|── app1
│   ├── common
│   └── static
└── app2

---

主分支的目录结构：

|── app1
│── common
│── static
└── app2

---

现在在主分支中，我更新文件夹“公共”和“静态”。然后，我将主分支合并到功能分支中，以更新“app1”下的“common”和“static”文件夹。然而，由于这两个分支的结构不相同，Git将认为这两个文件夹是新的。如何进行合并以更新功能分支？

两个分支的目录结构不是特别相关，除了与合并基提交相比

Git通过比较合并基本提交和两个分支提示提交来进行合并。因此，您的问题是错误的：它确实应该关注合并基提交与两个tip提交的比较。当然，如果两个分支提示提交具有不同的目录布局，则其中最多有一个可以匹配合并基的目录布局。但两者都有可能与该布局不匹配

当Git执行两个diff时，从merge base到tip#1，然后从merge base到tip#2，它在两个diff中启用重命名检测。如果重命名检测正确地找到所有重命名的文件，Git将正确地合并这些文件。无论Git在何种程度上无法正确识别相同内容和不同名称的文件，您都必须手动合并这些文件

您可以使用

-X find rename=

或

-X rename threshold=

参数在某种程度上帮助Git进行重命名检测。这个数字n是可以传递给

git diff

的与

-M

或

-查找重命名

相同的“相似性索引”参数。（

重命名阈值

名称是旧名称，最近更改，以便

git merge

的选项与

git diff

匹配）。请注意，git对多少文件进行重命名检测也有限制。

git merge

（现在1000个）的此限制默认值高于

git diff

（现在400个）。（这些限制在1.7.5之前的旧版本Git中较小，但都是可配置的；请参见中的

diff.renameLimit

和

merge.renameLimit

。另请参见）