Git 恢复合并冲突的初始列表

当git在合并时遇到冲突时，会显示一个列表，其中每个条目都以

冲突

开头，并包含有关冲突原因的信息，如

（重命名/删除）

我正在寻找一种方法，在重新启动机器或仅仅关闭CLI之后检索这个确切的列表

当然有：

git diff --name-only --diff-filter=U

但是，这并不包含有关冲突原因的信息，因此对于50多个文件来说，找出冲突的原因要比重置git和重新进行合并更费劲

这是否可以实现，例如使用

reflog

---

编辑：请注意，此问题专门针对所描述的列表，我不要求其他解决方案来解决合并冲突。

当仍处于合并状态时，如果运行

git status

，您将在

未合并路径

部分下找到文件，这些是冲突文件（根据冲突的类型，文件将标记为“均已修改”、“均已添加”、“均已删除”。）

---

一般来说，为了解决冲突，如果您使用

git mergetool

，它将自动遍历冲突文件。

git status

无法检索准确的列表，它是一开始发生合并冲突时收到的CLI消息的子集。很抱歉，我重新编写了更准确的命令（在实际发生冲突且未被内存响应后…），整个列表位于“未合并路径”下第节。如前所述，它与我要求的列表不同。我知道

git状态

，但它不包括冲突的原因，我特别要求列表包括以下条目：

冲突（重命名/重命名）：Rename->in

。使用

git status

我无法获得该信息。我将投票支持您的回答，因为这可能会解决某人在

git merge

中遇到的问题，但它无法回答我的问题。不幸的是，git在检测到重命名/重命名冲突后会删除一些重要信息。如果有只有一个这样的冲突，它是可恢复的，否则它会很棘手。（我认为这适用于重命名/删除冲突，通常重命名记录不正确。）我试图重现一个类似的冲突，以便更好地分析情况。@Mär，你能告诉我你正在使用的Git版本吗？@padawin version:

2.21.0.windows.1

，但是在你决定深入研究之前，我怀疑@torek关于一旦CLI输出被删除，这些信息就无法存储/检索的说法可能是正确的不再可用。很公平，很抱歉。别担心。此外，你的回答可能会帮助其他人。