如何合并 Git 分支并处理冲突分支让任务可以独立开发但开发成果最终仍要回到目标分支。git merge的关键规则是把指定分支的历史合入当前分支。因此合并之前要先确认三件事当前分支是不是接收成果的目标分支工作区是否干净两边的代码是否已经完成必要测试。先站到接收方分支假设要把feature/cache合入maingit switch main git status git merge feature/cache可以把第二条命令读成把feature/cache合并到我当前所在的main。如果站在feature/cache上执行git merge main方向就反了那是在把main的进展合入功能分支。快进合并只移动分支位置功能分支创建以后如果main没有产生新提交历史仍是一条直线A──B──C──D │ └─ feature/cache └──── main在main上合并feature/cacheGit 只需要把main从B移到DA──B──C──D ├─ main └─ feature/cache这种情况叫快进合并Fast-forward不会额外创建合并提交。命令输出中会出现Fast-forward历史仍然是一条直线也不会单独留下“这里曾经合并过功能分支”的提交。三方合并用一个新提交连接两条历史如果分支创建以后main和功能分支都产生了新提交历史会发生分叉A──B──C────E main \ D────F feature/auditGit 会比较共同祖先B、main的最新状态和功能分支的最新状态并创建一个新的合并提交A──B──C────E──M main \ / D────F feature/auditM有两个父提交分别连接合并前的两条历史。使用下面的命令可以观察结构git log --oneline --all --graph --decorate如果两边修改的是不同内容Git 通常能自动完成三方合并。输出会包含类似Merge made by the ort strategy.--no-ff 不是所有项目的固定答案即使一次合并能够快进也可以显式要求创建合并提交git merge --no-ff feature/cache这样做能保留功能分支的合并点但也会增加合并提交。是否使用--no-ff属于团队的历史管理选择不是 Git 的普遍最佳实践。有些团队保留合并提交有些团队在托管平台上使用 squash有些团队要求线性历史。进入项目后应先遵守仓库已有规范。冲突表示 Git 无法替人做决定三方合并不一定产生冲突。常见冲突场景是两个分支修改了同一文件的同一区域Git 无法判断最终内容应该是什么。冲突发生后合并会暂停CONFLICT (content): Merge conflict in settings.conf Automatic merge failed; fix conflicts and then commit the result.此时不要反复执行git merge先查看现场git status短状态中可能看到UU settings.confUU表示两边都修改了该路径而且冲突还没有解决。用一个最小实验制造冲突下面的实验在独立目录中运行mkdir merge-conflict-lab cd merge-conflict-lab git init -b main git config user.name Git Blog Lab git config user.email git-blogexample.invalid printf timeout30\n settings.conf git add settings.conf git commit -m chore: add settings在功能分支修改同一行git switch -c feature/slow-job printf timeout45\n settings.conf git add settings.conf git commit -m feat: extend timeout回到main把这行改成另一个值git switch main printf timeout60\n settings.conf git add settings.conf git commit -m fix: raise timeout现在执行git merge feature/slow-job文件中会出现类似标记 HEAD timeout60 timeout45 feature/slow-job HEAD到是当前分支的内容到 feature/slow-job是准备合入的内容。这些标记只负责展示两个候选版本不代表必须二选一。正确结果也可能是结合两边意图后写出的第三种内容。解决冲突的完整流程第一步理解两边修改的目的在编辑器中写出最终内容。例如timeout60 retry2必须删除全部冲突标记但“删除标记”本身不等于冲突已经正确解决。第二步检查差异并标记该文件已经解决git diff git add settings.conf git statusgit add在这里表示“这个路径的最终结果已经确认”不是简单选择某一边。第三步完成合并提交git commit也可以使用团队认可的合并说明git commit -m merge: reconcile timeout settings最后运行项目测试再查看提交结构git log --oneline --graph --decorate文本冲突消失只说明 Git 能保存结果不代表组合后的业务逻辑一定正确。发现时机不对时中止合并如果尚未完成合并提交可以尝试回到合并开始前git merge --abort这个操作通常会恢复合并前的状态。但如果合并前就存在复杂的未提交修改恢复过程可能变得困难因此更稳妥的习惯是合并前先让工作区保持干净。中止以后再次确认git status不要用reset --hard代替正常的冲突中止流程因为它还可能覆盖需要保留的工作区内容。删除功能分支前先确认结果合并并测试完成后可以安全删除本地功能分支git branch -d feature/slow-job删除分支不会删除已经进入main的提交。若-d拒绝删除应先弄清 Git 为什么判断它尚未合并而不是立即改用-D。总结git merge 分支会把指定分支合入当前分支。没有分叉时通常是快进只移动分支两边都产生新提交时会进行三方合并并用合并提交连接两条历史。冲突发生后正确顺序是查看状态、理解两边意图、编辑最终内容、git add标记解决、完成提交、运行测试。需要放弃时优先使用git merge --abort不要在不清楚影响时用破坏性命令清场。参考资料Git 官方资料Basic Branching and MergingGit 官方文档git-mergeGit 官方文档How conflicts are presented