Visual Studio处理Git合并异常的核心原则是先识别冲突类型再选择解决路径；绝大多数“异常”实为未解决冲突阻断提交，如“无法自动合并”常因冲突文件被排除或团队资源管理器未展开冲突列表所致。
Visual Studio 处理 Git 合并异常的核心原则是：先识别冲突类型，再选择图形化或命令行路径解决；绝大多数“异常”其实不是 Git 崩溃，而是未解决的冲突阻断了提交流程。
合并时提示“无法自动合并”但没显示冲突文件
这是最常被误认为“异常”的情况——实际是 Visual Studio 没在团队资源管理器中自动展开冲突列表，尤其当冲突文件被排除在解决方案之外（如 .gitignore 中的构建产物、bin/ 或 obj/ 目录下文件）时。
- 打开“团队资源管理器” → “更改”选项卡，手动滚动到底部查看“合并冲突”区域，它可能被折叠或隐藏
- 检查“输出”窗口（视图 → 输出 → 选择“Git”），搜索关键词
CONFLICT或error:，真实错误会在这里打印完整路径 - 若输出里出现
fatal: refusing to merge unrelated histories，说明两个分支无共同祖先，需加--allow-unrelated-histories参数，此时必须切命令行执行：git merge --allow-unrelated-histories <branch-name>
三窗格冲突编辑器里“保留此更改”无效
点击“保留此更改”后内容没变，或保存后仍报冲突，大概率是文件编码不一致或行尾符混用（CRLF vs LF），导致 Visual Studio 无法正确识别差异边界。
- 右键冲突文件 → “高级” → “以编码方式重新打开”，统一选
UTF-8（勿用 UTF-8 with BOM） - 在文件末尾按 Ctrl+Shift+P 打开命令面板，输入
Change End of Line Sequence，设为LF（Linux/macOS 风格）或与目标分支保持一致 - 若仍失败，直接关闭三窗格编辑器，用普通文本编辑器打开文件，手动删掉
<<<<<< HEAD、=======、>>>>>> <branch>这三行标记，再保存
合并后编译失败，但 Git 显示“已解决”
Git 只校验冲突标记是否清除，不校验语法或逻辑。常见于 C# 中 partial class 分布在多个文件、XML 注释格式错乱、或 .csproj 的 <Compile Include=...> 路径重复引入。
- 不要跳过“生成解决方案”步骤——合并提交前务必本地编译通过
- 若编译报
CS0104（类型名歧义），检查是否因合并引入了同名但不同 namespace 的类，需手动调整 using 或全限定名 - 对
.csproj文件，优先使用“保留传入更改”（即目标分支版本），再手动补入当前分支新增的<PackageReference>或<Compile>条目，避免重复
VS 卡死在“正在解决冲突…”或同步按钮灰显
本质是 Git 进程卡住或锁文件残留，不是 UI 崩溃。Visual Studio 本身不直接运行 git.exe，而是调用 libgit2，但锁状态依赖文件系统。
- 关闭 Visual Studio，删除项目根目录下的
.git/index.lock（如有）和.git/REBASE_HEAD（如有） - 在终端进项目目录，运行
git status确认是否处于merging状态；若是，用git merge --abort安全退出，再重试 - 若反复卡死，禁用 Visual Studio 的“Git 免打扰模式”（工具 → 选项 → 源代码管理 → Git → 取消勾选“启用免打扰模式”），避免后台操作被静默抑制
真正难处理的从来不是冲突本身，而是合并后未验证的语义一致性——比如一个分支改了 API 返回结构，另一个分支改了调用方逻辑，Git 能合并文本，但不会告诉你 JSON 字段名已失效。这类问题只能靠测试覆盖和人工走查兜底。
