git mergetool提示“no files need merging”是因为尚未进入冲突状态，它仅处理已标记为“unmerged”的文件；必须先触发合并失败（如修改同一行后执行git merge），再运行该命令。
git mergetool 命令执行后没反应或报错 “No files need merging”
这通常不是工具没装好，而是你还没真正进入冲突状态——git mergetool 只对已标记为“unmerged”的文件生效。它不会帮你检测冲突，也不会在 git merge 成功后启动。
必须先触发合并失败：比如在两个分支都改了 src/utils.js 的同一行，再运行 git merge feature/login，看到终端输出 CONFLICT (content): Merge conflict in src/utils.js 和 Automatic merge failed，这时才可执行 git mergetool。
常见误操作：
- 在
git status显示 “clean” 或只有 “modified” 时就跑git mergetool—— 它真会直接退出并提示 “No files need merging” - 执行了
git add但没git commit，误以为冲突已解决 —— 实际上git mergetool仍能运行，但只处理尚未git add的冲突文件 - 用
git merge --no-commit后手动git add了所有文件，再调git mergetool—— 此时确实无文件可处理
配置 meld / kdiff3 / vimdiff 作为默认 mergetool
Git 不自带图形界面工具，mergetool 只是调度器。你得先装好工具本体，再告诉 Git 怎么调用它。
以 meld 为例（Linux/macOS 常用）：
sudo apt install meld # Ubuntu/Debian brew install meld # macOS
然后配置：
git config --global merge.tool meld git config --global mergetool.meld.trustExitCode true
Windows 用户常用 kdiff3：
git config --global merge.tool kdiff3 git config --global mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" git config --global mergetool.kdiff3.trustExitCode true
关键点：
-
mergetool.<tool>.path</tool>必须写对绝对路径，尤其 Windows 下反斜杠要转义或用正斜杠 -
trustExitCode true表示信任工具返回值（成功=0），否则 Git 会多问一句 “Was the merge successful?” - 不设
path时，Git 会在PATH中找命令名，所以确保which meld或where kdiff3能定位到
运行 git mergetool 时卡在 “Hit return to start merge resolution…”
这是默认行为，Git 在等你确认是否真的要启动工具。加 -y 参数跳过提示：
git mergetool -y
或者一次性配置跳过：
git config --global mergetool.keepBackup false git config --global mergetool.prompt false
注意两个易忽略细节：
-
prompt false仅对命令行工具生效；GUI 工具（如 meld）本身可能还有自己的确认弹窗，那得看它自己的设置 -
keepBackup false很重要：默认 Git 会给每个冲突文件留一个.orig备份（如index.html.orig），不关掉的话，git status会持续显示这些未跟踪文件，干扰判断 - 如果只对当前项目生效，去掉
--global，改用--local
用 --ours / --theirs 快速跳过手工编辑，但别滥用
当冲突明确该以某一方为准（比如你确定要丢弃 feature/auth 分支对 package.json 的修改），可以用：
git checkout --ours package.json git add package.json
或一步到位：
git checkout --theirs -- src/api/client.ts git add src/api/client.ts
但注意：
-
--ours指当前所在分支的版本（HEAD），--theirs指被合并分支的版本 —— 这和直觉相反，尤其 rebase 场景下含义会翻转 - 它们只作用于已暂存的冲突文件，不能替代
git mergetool对多文件、多冲突块的批量处理 - 一旦执行，Git 就认为该文件“已解决”，不会再出现在
git mergetool列表里 —— 如果选错了，得用git restore --staged <file></file>撤回暂存，再重来
真正麻烦的从来不是工具怎么配，而是冲突块里那几行逻辑到底该留哪边、要不要合并条件分支、变量重命名是否兼容——这些没法靠 git mergetool 自动判断，得人眼比对上下文。
