Git：在未检测到的重命名中手动合并更改

这个问题使用Git

2.7.0.windows.1

，因此一些Git命令可能已经过时

如果我的

git merge

命令没有检测到重命名的文件，我如何告诉git手动合并两个文件中的更改（这两个文件应该是单个文件），而不重新开始合并并使用较低的重命名阈值

复制步骤：

git init
echo "//Hello world!" > hw.h
git add . && git commit -m "Initial commit"
git checkout -b someBranch
mv hw.h hw.hpp
echo "//Foobar" > hw.hpp
git add . && git commit -m "Change hw to HPP & change content"
git checkout master
echo "//Boofar" > hw.h
git add . && git commit -m "Change content of hw"
git merge -X rename-threshold=100% someBranch

您将得到合并冲突，但没有冲突块。也就是说，您应该得到的唯一冲突/错误是：

CONFLICT (modify/delete): hw.h deleted in branchB and modified in HEAD. Version HEAD of hw.h left in tree.
Automatic merge failed; fix conflicts and then commit the result.

和

git状态--ceral

将显示：

UD hw.h
A  hw.hpp

通常，在合并时，最好将检测重命名的阈值设置得足够低，以便检测到重命名，例如在我的例子中，我正在进行大规模合并（>1000个文件和大约9m LOC），我必须将重命名阈值提高到足以避免任何“误报”；从字面上看，我得到了大量错误检测到的重命名（我知道，重复的代码很糟糕）。按照我最终使用的值，我只得到了少量未完成的重命名，这似乎是一个更好的选择

---

TL；降低重命名阈值不是我的选择；在没有启动合并的情况下，如何告诉Git考虑<代码> HW.H.H./C>和<代码> HW.HPP<代码>是一个单一文件（有冲突），而不是两个文件，如上面所示？< /强>

< P>工具是有点KLUNKY，但它们在那里。 您需要确保合并本身在提交之前停止。在您的情况下，这会自动发生。对于更复杂的合并，Git认为自己做得正确，但实际上没有，您可以添加

--no commit

，但这会影响接下来的几个步骤。我们暂时不考虑那个问题

接下来，您需要获得有问题的文件的所有三个版本。由于Git因冲突而停止，我们的状态很好：三个版本都可以通过索引访问。请记住，我们关心的三个版本是合并基、

--我们的

、和

--他们的

如果Git正确地检测到重命名，那么所有三个版本都将位于索引中的一个名称下。因为它没有，所以它们不是：我们需要两个名字。（对于“Git认为它正确地进行了合并”案例，文件的合并基础版本根本不在索引中，我们必须以其他方式检索它。）您案例中的两个名称是

hw.h

和

hw.hpp

，因此现在我们这样做：

$ git show :1:hw.h > hw.h.base    # extract base version
$ git show :2:hw.h > hw.h         # extract ours
$ mv hw.hpp hw.h.theirs           # move theirs into place

（重新命名并不是绝对必要的，它只是为了帮助保持它的直线性和良好的图解。）

现在，我们要将一个文件与git merge file合并：

$ git merge-file hw.h hw.h.base hw.h.theirs

这将使用您配置的

merge.conflictStyle

，以便合并文件中的内容与您期望的一样，只是冲突行上的标签略有不同。我设置了

diff3

set，因此我得到：

$ cat hw.h
<<<<<<< hw.h
//Boofar
||||||| hw.h.base
//Hello world!
=======
//Foobar
>>>>>>> hw.h.theirs

这里的散列来自

gitls文件--stage

，是

hw.hpp

的散列。（需要第二步删除

hw.hpp

索引项。）

---

---

1使用git merge base--all查找所有合并基。如果有多个合并基，您可以任意选择一个（这是

-s resolve

所做的），或者尝试将所有合并基合并到一个虚拟合并基中。要合并两个合并基，您需要找到它们自己的合并基，并使用该合并基合并两个基，就像它们是分支提示一样。根据需要递归和迭代这是Git使用默认的

-s递归策略所做的，直到您拥有文件的单一合并基础版本。
用于此的工具有点不完善，但它们确实存在

您需要确保合并本身在提交之前停止。在您的情况下，这会自动发生。对于更复杂的合并，Git认为自己做得正确，但实际上没有，您可以添加
--no commit
，但这会影响接下来的几个步骤。我们暂时不考虑那个问题

接下来，您需要获得有问题的文件的所有三个版本。由于Git因冲突而停止，我们的状态很好：三个版本都可以通过索引访问。请记住，我们关心的三个版本是合并基、
--我们的
、和
--他们的

如果Git正确地检测到重命名，那么所有三个版本都将位于索引中的一个名称下。因为它没有，所以它们不是：我们需要两个名字。（对于“Git认为它正确地进行了合并”案例，文件的合并基础版本根本不在索引中，我们必须以其他方式检索它。）您案例中的两个名称是
hw.h
和
hw.hpp
，因此现在我们这样做：

$ git show :1:hw.h > hw.h.base    # extract base version
$ git show :2:hw.h > hw.h         # extract ours
$ mv hw.hpp hw.h.theirs           # move theirs into place

（重新命名并不是绝对必要的，它只是为了帮助保持它的直线性和良好的图解。）

现在，我们要将一个文件与git merge file

合并：

$ git merge-file hw.h hw.h.base hw.h.theirs

这将使用您配置的

merge.conflictStyle

，以便合并文件中的内容与您期望的一样，只是冲突行上的标签略有不同。我设置了

diff3

set，因此我得到：

$ cat hw.h
<<<<<<< hw.h
//Boofar
||||||| hw.h.base
//Hello world!
=======
//Foobar
>>>>>>> hw.h.theirs

这里的散列来自

gitls文件--stage

，是

hw.hpp

的散列。（需要第二步删除

hw.hpp

索引项。）

---

---

1使用git merge base--all查找所有合并基。如果有多个合并基，您可以任意选择一个（这是

-s resolve

所做的），或者尝试将所有合并基合并到一个虚拟合并基中。要合并两个合并基，您需要找到它们自己的合并基，并使用该合并基合并两个基，就像它们是分支提示一样。根据需要递归和迭代这是Git使用默认的

-s递归策略所做的，直到您拥有文件的单一合并基础版本。
顺便说一句，我感觉到了您的痛苦。我曾经尝试过这样的合并。我们最后使用了一个不同的