GitLab UI在线解决冲突需点击“Resolve conflicts”进入，左侧绿色为HEAD修改、右侧蓝色为目标分支修改，可点击“Use ours”或“Use theirs”按钮保留对应版本；但二进制文件、超200KB、非UTF-8编码、含残留冲突标记或路径不一致时必须改用命令行处理。
GitLab 的在线冲突解决界面能处理大多数文本类冲突，但不是万能的——二进制文件、超大文件、非 UTF-8 编码或已含冲突标记的文件，必须切回命令行。
GitLab UI 里怎么选“用我的”还是“用对方的”
进入 MR 页面点击 Resolve conflicts 后，每个冲突文件会分左右两栏：左侧绿色区域是 HEAD（你当前分支的修改），右侧蓝色区域是目标分支（比如 main）的改动。UI 提供两个快捷按钮：Use ours 直接保留左边全部内容，Use theirs 采用右边全部内容。
这种操作适合以下场景：
- 你确认对方改的是配置项或日志格式，而你的业务逻辑不能动
- 对方做了重构，你本地只是加了注释，想全盘接受重构结果
- 冲突集中在单个函数内，且双方修改互斥（比如一个删了字段，一个改了字段类型）
注意：Use ours 不等于“保留所有”，它只作用于当前冲突块；如果一个文件有多个冲突块，得逐个点。
什么时候必须放弃 UI，切到命令行
GitLab UI 会在文件不满足以下任一条件时禁用编辑功能：
- 文件是
.png、.pdf、.zip等二进制类型 - 文件大小超过
200KB - 文件编码不是
UTF-8（比如含GBK中文注释） - 文件里已经存在未清理的
<<<<<< HEAD标记（说明之前没解决完） - 同一文件在两个分支中路径不同（例如
src/api.jsvslib/api.js）
遇到这些情况，直接 git fetch origin 拉取最新，然后 git merge origin/main 触发本地冲突，用 VS Code 或 Vim 手动处理更可靠。
VS Code 内置冲突解决器怎么用才不翻车
VS Code 在打开含冲突标记的文件时，会高亮显示冲突块，并在行号旁提供三个操作按钮：Accept Current Change、Accept Incoming Change、Accept Both Changes。但要注意：
-
Accept Both Changes不是智能合并，它只是把两边代码都留下，中间不加空行——容易导致重复定义或语法错误 - 如果冲突块里有嵌套的 if/else 或对象属性重排，按钮方案大概率出错，必须手动删标记+重写逻辑
- 保存前务必检查是否残留
<<<<<<、=======、>>>>>>——漏删一个就会让git add失败
建议开启 VS Code 的 "git.autoRepositoryDetection": true，避免在错误工作区触发冲突操作。
真正麻烦的从来不是标记怎么删，而是删完之后那几行逻辑到底该听谁的——尤其是当两个人都在改同一个状态机或同一个 API 响应结构时，光靠工具选“左边”或“右边”根本不够，得看 commit message、看最近的 PR 讨论、甚至要找人对齐意图。这点工具永远代替不了人。
