为何`git ls-files --modified`在合并冲突时重复显示文件？

没错，这完全是Git的预期行为，背后和合并冲突时Git处理文件的底层机制有关，咱们来具体说说：

为什么会重复列出？ #

当Git遇到合并冲突时，它会把冲突文件的多个版本存到暂存区的不同「stage（暂存阶段）」里：

• Stage 1：冲突双方的共同祖先版本（如果这个文件在祖先提交中存在的话）
• Stage 2：你当前所在分支的文件版本
• Stage 3：你要合并进来的分支的文件版本

git ls-files --modified命令会扫描所有被修改的文件条目，包括这些不同stage里的同一个文件——每个stage对应的条目都会被单独列出，所以你会看到同一个文件名重复出现。

比如在你的测试场景里，两个分支都新增了file且内容不一样，Git会把这两个版本分别放在stage 2和stage 3，因此git ls-files --modified会输出两次file。如果是三方都有修改的复杂冲突，你甚至可能看到三次重复的文件名。

为什么git status只显示一次？ #

git status是面向用户的状态汇总工具，它会把同一个文件的多个unmerged stage条目合并成一条展示，只显示一次文件名，并标注冲突类型（比如both modified），所以你看不到重复的条目。这是为了让用户更清晰地理解当前的冲突情况，而不是暴露底层的暂存区细节。

验证一下底层状态 #

你可以用git ls-files --stage命令查看暂存区的详细状态，能清楚看到同一个文件对应的多个stage条目：

git ls-files --stage

在你的测试案例中，输出大概是这样的：

100644 a0b2c3d4e5f6 2	file
100644 f7e6d5c4b3a2 3	file

第二列的数字就是stage的编号，能直观看到同一个文件有两个不同的暂存条目。

如何获取唯一的冲突文件名列表 #

如果想通过git ls-files得到每个冲突文件仅出现一次的列表，可以结合去重命令，比如：

git ls-files --modified | uniq

或者直接针对unmerged状态的文件处理：

git ls-files --unmerged | cut -f2 | uniq

内容的提问来源于stack exchange，提问作者eedrah