Git冲突必须手动解决：一、编辑冲突文件删标记后提交；二、用git checkout --ours/theirs选版本；三、配merge.tool可视化合并；四、用git merge --abort中止合并。
Git 多分支冲突不能靠“猜谁改得对”来解决，必须明确谁在哪个分支改了什么、为什么不能自动合并、以及平台是否真能帮你少写命令。
GitLab MR 页面显示 “Resolve conflicts” 按钮但点不开
这通常不是权限问题，而是当前分支与目标分支的差异已超出 GitLab Web UI 的解析能力。GitLab 只允许在线编辑满足以下全部条件的冲突文件：
-
git diff --name-only --diff-filter=U列出的冲突文件不超过 3 个 - 每个冲突块长度 ≤ 15 行（含
<<<<< HEAD/=======/>>>>> branch-name标记） - 冲突文件未被重命名或同时被删除+新增（即非
RENAME或DELETED状态）
如果按钮灰掉或点击后空白，直接切到本地执行 git fetch origin && git checkout your-branch && git merge origin/target-branch，比等 UI 加载更省时间。
VSCode 内置 Git 面板里 “Accept Current Change” 和 “Accept Incoming Change” 选反了
这是新手最高频误操作——把 HEAD 当成“上游”，其实它永远指向你当前所在分支。例如你在 feature/login 分支发起 MR 合入 dev，点击 “Accept Current Change” 就是保留 feature/login 的修改，不是保留 dev 的。
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 看清楚编辑器顶部状态栏：左侧显示当前分支名（
feature/login），右侧才是目标分支（dev） - 冲突标记中
<<<<< HEAD下面的内容属于左侧分支，>>>>> dev下面属于右侧分支 - 如果 MR 是从
feature/login → dev，想用dev的逻辑覆盖本地，该点 “Accept Incoming Change”
SourceTree 中 “Launch External Merge Tool” 点击无响应
根本原因通常是 mergetool 配置缺失或路径错误，而非软件卡死。SourceTree 默认不预装任何外部工具，需手动指定。
- 先确认系统已安装工具，如
meld（Linux/macOS）或kdiff3（Windows），运行meld --version或kdiff3 --version验证 - SourceTree 菜单栏 → 工具 → 选项 → 合并工具 → 编辑现有工具或新增，填入完整路径：
/usr/bin/meld或C:\Program Files\KDiff3\kdiff3.exe - 勾选 “Auto-refresh file list after merge”，否则解决完冲突后文件状态不会自动更新
Gitee WebIDE 解决冲突后提交失败，报错 “Push rejected: You cannot push to this protected branch”
这不是代码问题，是 Gitee 分支保护规则拦截了直接推送。WebIDE 提交本质仍是 git push，而 dev 或 master 通常设为受保护分支。
- WebIDE 提交时，目标分支必须是你有写权限的源分支（即 MR 的 source branch），不能是 target branch
- 若 MR 是
feature/a → dev，WebIDE 必须提交到feature/a，而不是强行推到dev - 提交成功后，回到 MR 页面刷新，冲突状态会自动清除；若仍显示冲突，说明 WebIDE 没真正提交（检查右上角是否有绿色 “Committed” 提示）
真正麻烦的从来不是怎么点按钮，而是搞不清 HEAD 到底指谁、merge tool 为什么打不开、以及保护分支到底拦的是哪一次 push。这些细节不厘清，换十个平台都一样卡住。
