应先执行git status确认是否真处于合并中，再检查分支上下文、分叉关系及MERGE_HEAD状态；排查macOS特有干扰如行尾符转换、.DS_Store文件、系统锁；二进制文件需用外部工具人工合并；中断合并用git merge --abort清理。
遇到 git 合并冲突提示但实际没看到冲突文件，或提示异常（如“automatic merge failed”却无明确文件列表），在 macos 上需结合系统特性与 git 状态精准排查。核心不是直接删文件或强行提交，而是分步确认真实状态、排除干扰因素。
一、先确认当前 Git 状态和分支上下文
打开终端，进入项目根目录后立即执行以下命令：
- git status：查看是否真处于合并中（提示“merging”）、哪些文件标为“both modified”或“unmerged”；若显示“clean”，可能是上一次合并未完成残留
- git branch：确认当前所在分支，避免在错误分支操作
- git log --oneline --graph --all：观察当前分支与目标分支的分叉/交汇关系，判断是否真的存在可合并的差异
- git rev-parse HEAD 和 git rev-parse MERGE_HEAD：若后者有输出，说明合并正在进行中；若无输出但 git status 提示冲突，大概率是合并中断残留
二、检查 macOS 特有干扰项
macOS 的文件系统行为和工具链容易引发“伪冲突”：
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
-
行尾符（CRLF/LF）自动转换：某些编辑器（如 VS Code 默认启用）或 Git 配置（
core.autocrlf=true）可能在拉取/检出时悄悄改写二进制或脚本文件换行符，触发误报。运行git config --get core.autocrlf查看，建议设为input（macOS 推荐） -
资源派生文件（.DS_Store、图标缓存等）：若被意外纳入仓库，Git 会将其视为普通文件参与合并。用
git check-ignore -v .DS_Store检查是否被忽略；未忽略则补入.gitignore -
Spotlight 或 Time Machine 临时锁：极少数情况下，系统后台进程锁定文件导致 Git 读取异常。可尝试
lsof +D .查看是否有非 Git 进程占用工作区文件
三、定位冲突是否来自二进制文件
macOS 常处理设计稿、PPT、Xcode 工程等二进制文件，这类冲突 Git 不显示行级差异，仅提示“binary files differ”：
- 用
git ls-files -s <file>对比冲突文件在 HEAD 和 MERGE_HEAD 中的 blob SHA，若哈希不同，说明内容确实不同 - 用
file <file>确认文件类型，避免文本文件被误判为二进制（如 UTF-16 编码未声明 BOM） - 若确认是二进制（如 .psd、.xlsx），不要手动编辑冲突标记——直接用外部工具（Photoshop、Numbers）打开两个版本，人工合并后
git add <file>标记解决
四、清理中断合并状态
若确认无真实冲突但 git status 仍卡在“merging”状态，大概率是上次合并被强制退出（如 Ctrl+C、断电、编辑器崩溃）：
- 安全做法：
git merge --abort—— 这会回退到合并前状态，清除 .git/MERGE_HEAD、.git/index.lock 等临时文件 - 若
--abort失败（提示 index.lock 存在），手动删除：rm -f .git/index.lock（macOS 下无需 sudo，确保你有目录写权限） - 再运行
git status，应恢复干净状态；之后可重新git merge <branch>
