在团队协作开发中，Git合并代码是每天必做的基础操作。很多新手遇到合并报错或冲突时容易慌神，其实只要理清流程，掌握几个核心命令就能轻松应对。本文将用大白话带你一步步学会如何安全、高效地合并代码，避免踩坑。
合并前的准备工作
合并代码前必须先确保本地仓库是干净的。打开终端进入项目目录，运行git status查看当前状态。如果有未提交的修改，先用git add加上文件路径，再用git commit提交。如果不想保留这些改动，可以用git stash暂存起来。千万不要在混乱的状态下直接执行合并，否则很容易把错误代码带进主分支。同时建议提前拉取最新的主干代码，保证你的工作区基于最新的基准线，这样能减少后期冲突的概率。
常用合并方式对比
Git提供了merge和rebase两种主流合并策略，选对方法能让历史记录更清晰。merge属于快进式合并，它会生成一个新的合并节点，保留完整的分支历史，适合公共分支的协作场景。rebase则是变基操作，它会把当前分支的提交逐个重写到目标分支上，形成一条直线历史，看起来更整洁，但只推荐用于个人私有分支。日常开发中，如果你不确定该用哪个，默认选择merge是最稳妥的做法。
标准合并操作流程
第一步先切回到你要合并的目标分支，通常是main或者master。输入git checkout main后切换成功。第二步把远程主干的最新代码同步到本地，运行git pull origin main获取更新。第三步切回你正在开发的特性分支，比如feature-login，执行git checkout feature-login。第四步执行核心命令git merge main，此时Git会自动尝试将主干的代码融合到你的分支里。如果一切顺利，终端会提示Merge made by the recursive，说明合并成功。最后记得跑一遍单元测试和本地测试，确认功能没被破坏后再推送到远程仓库。
如何处理代码冲突
合并失败最常见的原因就是冲突。当两个分支修改了同一文件的相同区域时，Git无法自动判断该保留哪段代码，就会暂停并提示你手动解决。打开报错的文件，你会看到类似<<<<<< HEAD和>>>>>>> feature-login这样的分隔标记。中间夹杂的部分就是冲突内容，你需要根据业务逻辑决定保留谁的代码，或者直接重写一段新逻辑。删掉所有分隔符号后，用git add把冲突文件标记为已解决，接着运行git commit完成合并提交。如果中途发现改乱了想放弃这次合并，可以直接执行git merge abort回退到合并前的状态，完全不用担心搞坏项目。
高级技巧与避坑指南
为了避免频繁冲突，建议在开发周期较短的功能分支上优先使用rebase保持历史干净。大型团队可以配置pre-commit钩子自动检查代码规范，减少人为失误。合并后务必及时删除已经合入的旧分支，保持仓库整洁。另外不要直接在主干分支上写新功能，永远通过特性分支隔离开发，这是Git协作的黄金法则。遇到复杂的历史重写问题时，养成定期备份远程仓库的习惯，或者让同事协助审查关键合并操作，能大幅降低生产事故风险。平时多打标签记录版本节点，也能在紧急回滚时提供可靠依据。
