在前面的课程中，我们已经掌握了基础的分支创建、切换与查看方法。很多开发者在实际团队协作时都会卡在一个环节：两个人同时修改了同一个文件，或者改到了相近的代码行，最后提交时终端直接报错停止。这就是典型的合并冲突。今天这课不讲枯燥的理论，直接切入实际开发中最核心的分支合并策略，手把手教你拆解冲突，理顺提交历史。
为什么合并历史会影响后续维护
项目规模一旦扩大，分支交叉就成了常态。如果你习惯性地使用 git merge 命令，虽然能顺利完成任务，但提交日志会变成一张错综复杂的蛛网。每次合并都会强制生成一个额外的 merge commit，导致主干历史臃肿不堪。当线上出现紧急 bug 需要回溯某次代码变更的上下文时，这种杂乱的图谱会让排查效率大打折扣。清晰的版本演进脉络，直接关系到团队后期的迭代速度与容错能力。
merge 与 rebase 的选择逻辑
Git 内置了两种合并路径，核心差异在于是否改动原有提交记录。merge 属于非破坏性合并，它忠实地保留所有原始操作轨迹，将两条分支线交汇于一个新的节点。这种方式最安全，特别适合公共主干或长期迭代的稳定分支。rebase 则属于历史重写操作，它会把你当前分支的修改逐一切下来，粘贴到目标分支的最新提交之后。执行完后，提交记录会呈现为一条笔直的线段，没有任何分叉节点。这种写法非常整洁，但前提是你操作的必须是尚未推送给他人的私有分支。一旦涉及公共仓库，强行 rebase 会导致协作者的本地副本与服务器历史脱节，引发灾难性的同步问题。
冲突产生的底层原理与拆解步骤
冲突并非系统故障，而是 Git 在无法自动决策时的自我保护机制。当你收到 CONFLICT 警告并打开冲突文件时，会发现代码被特殊的锚点符号包裹。这些符号明确划分了来源区间，左边是当前分支的版本，右边是目标分支的版本，中间是待确认的差异区。此时你需要结合业务逻辑进行人工干预，保留正确实现，剔除冗余代码，并确保语法完整无误。清理完锚点符号后，必须立即执行 git add 指令标记该文件已修复，随后运行 git commit 即可完成整个合并流程。如果在处理过程中发现逻辑彻底混乱，可以直接输入 git merge --abort 终止操作，回到合并前的干净状态重新规划。
高频使用的可视化工具
光靠终端文字很难直观感受分支走向，强烈建议在项目中集成图形化查看器。通过 git log --all --graph --oneline --decorate 这条组合命令，你可以直接在控制台看到立体的分支拓扑结构。配合 SourceTree 或 GitKraken 等第三方客户端，拖拽即可预览合并后的历史形态。提前观察拓扑变化，能有效规避误操作带来的历史断裂风险，让你在执行关键指令前心里有底。
团队协作的标准化动作
成熟的开发流离不开固定的同步节奏。建议每位成员每天首次登录环境时，先拉取远程最新代码，再切回个人功能分支执行 rebase 操作。这样能把潜在的碰撞点前置消化，避免临近交付时集中爆发。合入主干前务必在独立沙箱环境中跑通核心用例，确认依赖库版本匹配。对于跨部门联调项目，应引入代码评审拦截机制，合并请求必须经过至少一名资深成员签字放行。保持小步快跑、高频同步的习惯，远比事后花费大量时间修补版本库要高效得多。
