git status可快速识别冲突文件，明确列出unmerged路径及三类状态；可用--ours/--theirs批量取舍，注意rebase中含义反转；--no-commit配合reset实现可控合并；二进制文件冲突无文本标记。
git status 一眼看出哪些文件冲突了
执行 git merge 后如果失败，第一反应不是打开编辑器，而是先跑 git status。它会明确列出状态为 Unmerged 的文件，比如：
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/utils.js
both modified: package.json
deleted by them: README.md</file>
注意三类常见状态：both modified（双方都改了同一文件）、deleted by them（对方删了，你改了）、added by them（对方加了新文件，你本地没这文件但有同名修改）。每种都需要不同策略，别一概用“保留我的”糊弄过去。
用 git checkout --ours / --theirs 快速批量取舍
当多个文件冲突但你明确倾向某一方（比如：所有改动都以当前分支为准），不用逐个打开编辑。直接用 Git 内置的检出选项：
-
git checkout --ours -- src/：把src/下所有冲突文件全部覆盖为当前分支版本 -
git checkout --theirs -- package.json：只对package.json取对方版本 - 执行后必须
git add这些文件，否则 Git 仍认为冲突未解决
⚠️ 警告：--ours 和 --theirs 在 rebase 场景下含义会反转——此时 --ours 指的是“被 rebase 的那个分支”，容易搞混。只要你在 merge 流程中，就按字面理解：ours = HEAD 所在分支，theirs = 被合并进来的分支。
使用约定式提交信息暂存、提交和推送git更改。当用户想要提交和推送更改、提到推送到远程、或要求保存并推送工作时触发。也适用于用户说“推送更改”、“提交并推送”、“推送这个”、“推送到github”或类似git工作流程请求时。
跳过手动编辑：git merge --no-commit + git reset
如果你发现冲突太多、改得乱，又不想丢掉当前工作区，可以临时中止自动合并流程，改用更可控的方式：
- 先用
git merge --no-commit feature-x：Git 会把变更拉进来但不自动生成合并提交，给你留出检查窗口 - 此时运行
git status，所有冲突文件显示为Unmerged，但工作区已包含双方修改（含冲突标记） - 你可以
git reset --hard HEAD回退到合并前状态，或git checkout -- .清空工作区再重来
这个组合特别适合 CI/CD 流水线脚本里做预检：先试合并，失败就立刻退出，不污染工作区。
二进制文件冲突不能靠文本标记
图片、PDF、.docx、.psd 这类文件一旦冲突，git status 会显示 both modified，但打开文件看不到
- 用
git ls-files -s path/to/file查看两个版本的 blob hash，确认是不是真改了内容（有时只是时间戳变动） - 用
git show :1:path/to/file > base.bin提取基础版本，再用外部工具（如pdfdiff、xxd）比对差异 - 团队应约定：二进制资产统一由专人维护，或改用 LFS（Git Large File Storage）托管，避免多人直编
最常被忽略的一点：git add 二进制冲突文件时，Git 不校验内容一致性——你删掉冲突标记但没真正更新文件内容，git add 仍会成功，后续 git commit 会把错误版本合进去。务必用 git diff --cached 确认暂存区内容符合预期。
