本文详细讲解如何在基于 git2go 的实时协作编辑器中正确识别、展示并最终解决 Git 合并冲突，避免重复触发相同冲突，确保 git add/commit/push 流程在多人并发编辑时保持一致性与可靠性。
本文详细讲解如何在基于 git2go 的实时协作编辑器中正确识别、展示并最终解决 git 合并冲突，避免重复触发相同冲突，确保 `git add/commit/push` 流程在多人并发编辑时保持一致性与可靠性。
在使用 git2go 构建实时协作环境（如 Live Editor）时，一个常见却容易被忽视的关键问题是：冲突发生后，用户手动编辑并保存文件，但再次执行 add/commit/push 时，系统仍报告相同的冲突。这并非 git2go 的 Bug，而是因未正确完成 Git 的“冲突解决闭环”所致——即：Git 要求不仅修改工作区文件，还必须显式标记冲突已解决（通过 git add），再提交合并结果。而原代码中缺失了这一关键步骤，导致 Git 状态始终停留在 MERGING 阶段，每次拉取都会重新触发冲突分析。
✅ 正确流程：三步闭环解决冲突
检测冲突 → 呈现给用户
调用 index.HasConflicts() 判断是否存在未解决冲突；若为 true，将冲突标记（<<<<<<<, =======, >>>>>>>）注入编辑器界面，并立即返回错误，中断后续操作（如 push）。此时 Git 处于 MERGING 状态，索引中保留冲突条目。用户编辑 → 显式标记已解决
用户手动编辑文件、移除冲突标记、保存内容后，必须再次调用 index.AddAll(...) 将该文件重新加入索引（相当于命令行中的 git add <file>）。这是最关键的一步：它会从索引中清除对应路径的冲突项（git_index_conflict_remove），使 HasConflicts() 返回 false。提交合并 → 清理状态
成功 AddAll 并 index.Write() 后，即可安全创建合并提交（CreateCommit with two parents），最后务必调用 repo.StateCleanup() 清除 .git/MERGE_HEAD 和 MERGE_MODE 等临时状态，否则下次操作仍将触发冲突流程。
? 关键代码修正要点（对比原逻辑）
// ✅ 正确：在用户提交“解决后”的变更前，必须重新 AddAll
index, _ := repo.Index()
index.AddAll([]string{"path/to/conflicted/file.js"}, git.IndexAddDefault, nil) // 或用 []string{} 添加全部
index.Write() // 提交索引变更，清除冲突标记
// ✅ 确保 HasConflicts() 已返回 false 后，再创建合并提交
if !index.HasConflicts() {
treeId, _ := index.WriteTree()
tree, _ := repo.LookupTree(treeId)
repo.CreateCommit("HEAD", sig, sig, "Merge commit", tree, localCommit, remoteCommit)
repo.StateCleanup() // ⚠️ 不可省略！
}? 注意：index.AddAll([]string{}, ...) 在冲突状态下只会添加“非冲突文件”，不会自动清理冲突条目。必须显式指定冲突文件路径（或确保其被包含在通配范围内），才能触发冲突元数据清除。
? 常见陷阱与规避建议
- 不要跳过 StateCleanup()：遗漏此调用将导致 Git 持续认为处于合并中，后续所有 MergeAnalysis 均返回 MergeAnalysisNormal，无限循环冲突提示。
- 避免重复 Merge 调用：repo.Merge(...) 仅用于初始合并准备（生成冲突索引），不可在用户编辑后再次调用——此时应直接走“Add → Commit”路径。
- 区分“首次冲突”与“二次同步”：用户解决冲突并提交后，下一次 Pull 仍需执行完整 Fetch + MergeAnalysis，但此时因本地 HEAD 已前进，analysis&git.MergeAnalysisUpToDate 将为 true，跳过合并流程，保障性能。
✅ 总结：构建健壮协作 Git 流程
Git2go 的冲突处理本质是状态机驱动：MERGING → （用户编辑 + AddAll + Write）→ INDEX_CLEAN → CREATE_COMMIT → StateCleanup() → READY。严格遵循此闭环，即可实现与 CLI git merge 行为完全一致的体验——既支持实时可视化冲突，又保证解决后的一次性提交成功，彻底杜绝“冲突幽灵”问题。
