合并冲突怎么处理：先认清分支，再验证语义

合并冲突怎么处理先认清分支再验证语义合并冲突和代码评审都不靠“更熟练地敲命令”解决。前者需要保护共享历史后者需要把机械检查和设计判断分开。1. 先区分分支类型个人且未共享的短生命周期分支可以在同步主干后 rebase便于整理提交历史。已经被多人基于其开发的分支不应擅自 rebase 或 force-push这会重写共同历史增加其他人的恢复成本。是否允许强制推送应由仓库保护规则和团队约定决定。场景常见做法注意事项未共享的个人分支rebase 到目标分支推送前确认没有他人依赖该历史多人共享分支merge 目标分支不重写公共提交复杂业务冲突找到改动负责人共同确认不能用ours或theirs代替业务判断2. 解决冲突的基本流程先确保工作区可恢复再把目标分支合入当前分支逐个阅读冲突块上下文。完成后运行与改动相符的测试不要为了结束冲突而删除任一侧逻辑。git switch feature/my-change git fetch origin git merge origin/main git status git diff --check冲突解决后根据项目语言运行测试、类型检查或构建。git mergetool可以辅助查看三方差异但最终选择仍需理解业务语义。3. 让自动化和人工评审各司其职格式、未使用代码和部分静态问题适合交给格式化工具、linter 与 CI。人工评审应重点关注接口兼容性、错误处理、资源释放、并发模型、权限边界、数据迁移和可观测性。下面的查询示例体现两个常见检查点透传上下文以及在错误中保留足够但不敏感的诊断信息。func (r *UserRepository) Get(ctx context.Context, id int64) (*User, error) { row : r.db.QueryRowContext(ctx, SELECT id, name FROM users WHERE id ?, id) var user User if err : row.Scan(user.ID, user.Name); err ! nil { if errors.Is(err, sql.ErrNoRows) { return nil, nil } return nil, fmt.Errorf(get user %d: %w, id, err) } return user, nil }超时应由调用链的边界统一设定仓储层不宜无条件覆盖上游的 deadline。4. 共享历史要克制冲突要验证共享历史需要克制冲突需要理解评审需要把人的注意力留给高风险决策。把这些边界写进仓库规则和检查项团队协作会更可预测。