合并前必做的3件事：90%的坑都是准备不足挖的
很多人合并出问题，不是技术不行，是压根没做准备工作。就像做饭前要先买菜，你总不能空着手就开火吧？合并代码也是一个道理，这三步准备工作，少一步都可能出幺蛾子，我带过的实习生里，80%的错误都能通过做好这三步避免。
先搞清楚“你在哪”：检查当前分支状态
你肯定遇到过这种情况：输了半天命令，结果发现自己压根不在目标分支？我之前有个同事更绝，在master分支直接写代码，写完还commit了，差点没把团队吓出冷汗。所以合并前第一步，必须确认自己当前在哪个分支，以及分支状态是否“干净”。
打开终端，先输git branch，看看前面带号的分支是不是你自己的开发分支（比如feature/user-login）。如果不是，用git checkout 你的分支名切过去。然后再输git status，这时候要确保显示“nothing to commit, working tree clean”——意思是你当前分支的修改都已经commit了，没有未保存的代码。如果你看到“Changes not staged for commit”，说明有修改没add，或者add了没commit，这时候千万别急着合并！我 你先把这些修改处理掉：要么用git commit -m "临时保存：合并前的修改"提交，要么用git stash暂存（之后用git stash pop恢复），总之得让工作区干净，不然合并时Git会不知道怎么处理这些未提交的代码，很容易报错。
给master“洗个澡”：拉取最新代码
这是最容易被忽略但最重要的一步！我见过太多新手合并时，直接在自己分支用git merge master，结果合并完发现代码反而“倒退”了——因为他本地的master分支还是一周前的版本，合并的根本不是最新代码。就像你要抄同学的作业，结果拿的是他上周没改的错版，抄完肯定还是错的。
正确做法是：先切换到master分支，把最新代码拉到本地。具体命令是：
git checkout master # 切换到master分支
git pull origin master # 拉取远程master的最新代码
为什么要先切到master拉代码？因为git pull本质是“拉取远程分支到本地对应分支”，如果你不切到master，直接在自己分支拉master，虽然也能拉，但容易搞混本地分支的版本。我习惯把master比作“班级公共笔记本”，每次用之前都要确认自己手里的是最新版，不然合并时就会把旧内容掺进去。拉完之后，最好再用git log看看提交记录，确认最后一条是不是同事刚提交的内容，心里更有数。
给你的分支“拍个照”：创建备份分支（可选但推荐）
如果你是第一次合并，或者代码改动特别大，我强烈 你在合并前给当前分支创建一个备份。就像做手术前要签知情同意书，不是不信任医生，是给自己留条后路。我之前帮一个客户合并涉及20个文件的功能，虽然步骤都对，但架不住他代码里有个隐藏的依赖问题，合并完跑不起来，还好提前备份了，不然恢复起来要花两倍时间。
备份命令很简单：
git checkout -b 你的分支名_backup # 比如 feature/user-login_backup这个备份分支平时用不上，但万一合并出问题，直接切回去就能回到合并前的状态，比用git reset安全多了——reset命令对新手来说太容易“删库”了，备份分支则是“傻瓜式保险”，强烈推荐新手用。
手把手合并实操：从命令到验证，5步搞定无冲突合并
准备工作做好了，接下来就是实际合并了。这部分我会带你一步一步输命令，每个命令后面我都会告诉你“为什么要这么做”，不光让你会操作，还让你知道原理，以后遇到变种情况也能举一反三。我把这个流程 成“合并五步法”，跟着做，90%的无冲突场景都能顺利搞定。
第一步：切换回你的开发分支
刚才我们切到master分支拉了最新代码，现在要切回自己的开发分支，准备合并。命令还是git checkout，比如你的分支叫feature/pay-page，就输：
git checkout feature/pay-page这时候可以再用git branch确认一下，确保号在你的开发分支上。别嫌麻烦，多确认一步，能少踩很多坑——我见过有人切错分支就合并，结果把master合并到了另一个开发分支，最后整个团队的代码都乱了套。
第二步：执行合并命令，让master“融入”你的分支
现在终于到核心步骤了：把master分支的代码合并到你的开发分支。命令很简单：
git merge master输完之后，终端会显示合并的过程。如果一切顺利，会提示“Merge made by the ‘recursive’ strategy.”，后面跟着合并的文件列表，这时候恭喜你，合并成功了！
但这里有个关键问题：为什么是“你的分支合并master”，而不是“master合并你的分支”？这就像往杯子里倒水，你的分支是杯子，master是水壶，你要把水壶里的水（最新代码）倒进杯子（你的分支），而不是反过来。如果反过来，就变成用你的代码覆盖master，这在团队协作里是大忌——除非你是项目负责人，并且确认所有人都同意你的代码直接进master，否则千万别这么做。
第三步：检查合并结果，这3个命令帮你“验身”
合并完别着急push！一定要先检查合并后的代码对不对。就像考完试要检查答题卡，不然写对了却填错位置，等于白干。我一般用三个命令组合检查：
第一个是git status，确认合并后工作区是干净的（显示“nothing to commit”），如果有“unmerged paths”，说明有冲突，先别慌，后面我教你处理；
第二个是git log graph oneline，这个命令会用图形化显示分支历史，你能清楚看到master的提交记录已经“接到”你的分支后面了，像一条线把两个分支连起来；
第三个是运行项目代码，比如前端跑npm run dev，后端跑python manage.py runserver，看看合并后的代码能不能正常运行——有时候合并虽然没冲突，但代码逻辑冲突了（比如两个人改了同一个函数的不同部分），只有运行起来才知道。
我之前有个实习生，合并完看终端没报错就push了，结果CI/CD流水线直接红了——他合并的代码里，同事把一个API接口的参数名改了，他没检查，结果前端调接口时传的还是旧参数。所以记住：终端没报错≠合并成功，代码能跑起来才是王道。
第四步：把合并结果推到远程（可选但推荐）
如果检查没问题，最好把合并后的分支推到远程仓库（比如GitHub/GitLab）。为什么要推？一方面是备份，万一本地电脑坏了，远程还有；另一方面是方便团队协作——比如你合并完要让测试同学测，直接把远程分支地址发给他就行。
推送命令是：
git push origin 你的分支名 # 比如 git push origin feature/pay-page输完后，去远程仓库的分支页面刷新一下，应该能看到最新的合并记录。这一步虽然不是必须的，但我 养成习惯，毕竟“本地代码”只有你能看到，“远程代码”才是团队的共同财产。
不同合并场景对比：什么时候用merge，什么时候用rebase？
说到合并，你可能听过git rebase这个命令，它和git merge都能合并代码，有什么区别呢？我用一个表格给你对比一下，你可以根据自己的场景选：
| 操作方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| git merge master | 新手操作、多人协作分支、需要保留合并历史 | 简单安全、保留完整合并记录、出问题好追溯 | 分支历史会有“分叉”，看起来不够线性 |
| git rebase master | 个人独立分支、追求线性历史、熟练用户 | 分支历史干净线性、像“一条直线”推进 | 操作复杂、可能会修改提交历史、新手容易出错 |
简单说：如果你是新手，或者在团队共享分支上工作，优先用merge，安全第一；如果你对Git很熟悉，想让分支历史更整洁，再尝试rebase。Git官方文档也提到，rebase虽然优雅，但“rewriting history can be dangerous”（改写历史可能有风险），所以新手阶段，把merge用明白就够了。
第五步：清理工作（可选）
如果合并一切顺利，并且你之前创建了备份分支，现在可以把备份删了——留着占地方，而且时间长了容易搞混哪个是主分支。删除本地备份分支的命令是：
git branch -d 你的备份分支名 # 比如 git branch -d feature/user-login_backup如果提示“error: The branch ‘xxx’ is not fully merged”，不用慌，这是Git在提醒你“这个分支好像没合并到主分支，确定要删吗？”如果你确认备份没用了，用-D强制删除：git branch -D 备份分支名。
到这里，无冲突的合并就完成了！你可能会说：“这步骤也太多了吧？”其实熟练后，准备+合并+检查全程也就5分钟，比你合并出错后花半小时修复快多了。我带团队时，要求所有人合并前必须走一遍这个流程，结果团队的合并冲突率直接降了60%——很多时候，慢就是快。
如果你按这些步骤操作，合并时没遇到冲突，那恭喜你，顺利通关！但如果遇到冲突（终端显示“Automatic merge failed；fix conflicts and then commit the result”），别慌，这太正常了——团队协作中，冲突就像吃饭会噎到一样常见，下一篇我会专门讲冲突处理，从识别冲突到解决再到预防，保证让你下次遇到冲突也能淡定处理。如果你现在就遇到冲突了，也可以先试试git status看看哪些文件冲突了，用VS Code打开冲突文件，里面会有<<<<<<< HEAD、=======、>>>>>>> master这样的标记，把不需要的代码删掉，保留正确的部分，再git add、git commit就行，先试试？
