凡是手动玩过几个项目的Git用户最后都会撞上同一个关卡把自己写的分支代码合并到master主分支。这个操作听起来简单——无非就是git merge可真正上手之后你会发现合并前要检查的事情、合并中冒出来的冲突、合并后回滚的方案每一环都可能让人头疼。我见过有同事直接在master上改代码也见过有人把功能分支合并回去之后发现一堆无关提交混了进来还有人在服务器上敲完merge才想起来当前分支根本不在master。这篇文章不绕弯子把“分支代码合并给master主分支”这件事从头到尾拆开讲先搞清楚合并的本质再分别讲merge和rebase两条路线最后把冲突解决、合并后回滚和团队协作规范一并写清楚。适合刚学Git没多久、对合并没有把握的新手也适合已经用了一段时间、但总在合并细节上翻车的兄弟。1. 合并之前要先想清楚你和master的关系1.1 分支从哪来master又为什么特殊我们可以把Git仓库想象成一条不断向前延伸的时间线master就是这条时间线上最稳定、最被信任的那一段。绝大部分团队会把master当作生产环境的唯一真相来源凡是发布出去的版本基本都从master上打标签切出去。而分支则是从这条主线上分出去的临时开发线路多个功能可以并行开发、互不干扰最后再把开发结果汇总回master。这个“汇总”的动作就是本文说的分支合并。这里有个关键点master的特殊性并不是Git天然强制规定的而是团队约定出来的。Git只要求你有一个默认分支至于这个分支叫什么、用来干什么完全看项目规范。很多团队会用保护规则禁止直接向master推送要求所有改动必须经过分支合并和代码评审目的就是让master始终保持在“可发布”的状态。理解了这一点你就明白为什么不能在master上随手改代码——你改的不是自己的代码而是整个团队的“地基”。我习惯打个比方master就像房子的主体结构分支是正在进行独立装修的房间。每个房间可以按自己的节奏施工但最终都要和主体结构对接。对接出错墙对不上管线接错那就是合并冲突对接成功整个房子才完整交付。1.2 合并的本质串起两条时间线不是复制粘贴很多新手把合并理解成“把某个分支的文件复制到另一个分支”这个理解会带来不少误操作。Git的每次提交记录的是一个完整的项目快照同时带有指向父提交的指针所有提交串起来就是一张提交图。合并的本质是把两条分叉的提交历史重新接起来让另一条线上产生的新提交也能完整出现在目标分支的历史里。分两种情况理解第一种master自打分支出去之后一直没有新提交分支顶端可以顺着原来的父提交一路回溯到master那么Git只需把master的指针一路快进到分支顶端这个操作叫fast-forward简单得像移动指针。第二种分支出去的这段时间里master上也有了新的提交两条线真正分叉了Git就不能简单移动指针得做一次三方合并拿两个分支的最新版本和它们共同的祖先提交做对比生成一个新的合并提交merge commit。搞清楚这个本质很多现象就好解释了为什么有时候merge之后历史是直线有时候却多了一个“Merge branch”节点为什么有的合并会冲突、有的不会答案都在提交图的结构里。2. 最稳的合并方式git merge 实操全解2.1 合并前必须做的三件事实际项目里我强烈建议任何一次合并之前先把下面三件事做掉能省掉大半的麻烦。第一确认当前工作区干净或者至少清楚有哪些未提交的改动。执行git status看到工作区干净再继续。如果有一半写完没提交的代码先commit或者git stash暂存起来。我曾经急着合并结果把写了一半的调试代码一起带进了master后来花了二十分钟清理。第二切换到master并把远程最新代码拉下来。很多人直接在自己本地过时的master上合并结果合并出来的历史里根本没有同事的提交push的时候才被远程拒绝或者干脆覆盖掉别人的工作。正确的做法是执行下面的命令先把本地master和远程对齐git checkout master git pull origin master第三预览一下两个分支的差异。用git diff --stat master feature看一眼要合并进来的改动大概涉及哪些文件、量有多大。如果差异比你预期的多几十个文件很可能你的分支不是从当前master拉出来的或者中间同步过太多东西这时候就要谨慎判断不要盲目执行merge。2.2 三种合并结果快进、三方合并、冲突执行git merge feature之后到底会发生什么取决于两个分支的历史关系。第一种是fast-forward快进合并。分支点之后master没有新的提交Git直接把master指针推到feature分支顶端。历史保持直线没有任何多余节点非常干净。缺点是看不出这个功能是哪个分支合进来的因为根本没有合并痕迹。第二种是recursive三方合并。两条线分叉了Git找到两个分支的共同祖先对比三个版本自动合并成功后默认生成一个merge commit。这个提交会记录“两个分支曾经交汇在此”回溯起来非常清晰。第三种是冲突conflict。Git自动合并不了同一文件里的抵触修改它会停下来在工作区里留下冲突标记等你手动处理。遇到冲突不用慌这是正常流程的一部分下一章我会专门展开讲这里你只需要知道冲突不是错误而是Git在向你确认“这里有两个修改都合理你来决定”。2.3 --no-ff、--squash、--no-commit 该怎么选基础merge命令很简单但几个参数能让它适应不同的团队规范我逐个说说我的用法。git merge --no-ff feature是我在团队里最常用的写法。即使master没有新提交、理论上可以快进我也强制它生成一个merge commit。这样做的好处是在master的历史上能清楚地看到一个独立的“集成分支”节点顺着这个节点你能知道某个功能是何时、从哪个分支合入的。对需要写发布记录、做版本回溯的团队来说这个信息非常值钱。很多开源项目之所以历史里全是“Merge pull request #xxx”节点就是这个原因。git merge --squash feature则是把feature上的所有提交压缩成一个统一的改动放在master的工作区里不自动生成提交需要你手动git commit。适合那些功能分支上有一堆“改文案”“微调样式”这种无关紧要的提交、而你只想在master上留下一个干净提交的场景。坏处是feature的详细开发过程不会进入master历史将来要追溯单个改动这些细节就丢了。git merge --no-commit feature会在合并完成后停在“已合并但未提交”的状态不产生merge commit方便你检查合并结果再决定提交。我一般用在跨越较大、心里没底的合并上多一步确认的保险。三个参数也可以组合使用比如--no-ff --no-commit既留下合并节点又保留检查环节。3. 想保持线性历史rebase合并思路详解3.1 rebase和merge的核心区别历史是平还是弯merge和rebase解决的是同一件事——把feature的提交接到master上但结果相差很大。merge保留两边的真实提交最后交汇成一个合并节点历史像一棵有分叉的树rebase则是把feature上的提交一个接一个地“重放”到master当前顶端重新生成一批内容相同、但哈希值全新的提交历史变成一条笔直的线。简单对比假设master有3个提交feature在上面又提交了5个与此同时master自己也新增了2个提交。用merge合会得到325个提交外加1个merge commit用rebase合会得到325个提交但没有任何merge commit一条线直通到底。为什么有的人特别偏爱rebase的线性历史因为可读性好、好回溯。git log --oneline一眼扫下来每次提交顺序清清楚楚不会出现“Merge branch xxx into master”这种噪音节点。为什么有人又坚决不用因为rebase重写了一边提交在协作中一旦对公共分支使用可能引发大麻烦。这是后话下面细说。3.2 rebase合并实操把feature变基到最新master具体操作分两步先把master更新到最新再把feature变到master上。先进入feature分支执行变基git checkout feature git rebase masterGit会把feature上自共同祖先以来的所有提交逐个摘下来按顺序重放到当前master的最顶端。这里要注意rebase和merge在冲突处理上有个明显区别merge只做一次三方比对、冲突只出现一次而rebase是逐个提交重放如果每个提交都碰到改动的区域就会一个接一个地触发冲突。中途冲突的话Git会停在冲突提交处提示你解决改完文件后git add然后git rebase --continue直到所有提交都重放完毕。第二步回到master侧。因为此时master的历史严格包含了feature的提交直接git merge feature会发现这本质上是fast-forward把master指针快进到feature的顶端。更保险的写法是加--ff-only如果Git发现无法快进会直接拒绝你而不是自作主张生成merge commit也就不会产生意料之外的合并节点git checkout master git merge --ff-only feature git push origin master3.3 什么情况下千万别用rebase这里必须专门标一下风险已经push到远程并且别人已经基于它继续开发的分支绝对不要rebase。一旦你把这样的分支rebase提交哈希全部变了所有基于旧提交的新提交会因为找不到自己的父提交而变得极其混乱协作者的仓库会冒出“幽灵提交”“重复提交”比merge冲突难处理十倍。个人经验是在我的团队里rebase只允许发生在还没有推出远程的本地分支上。一旦分支把改动push出去不管看起来多乱后续统一用merge来汇总。宁可多点合并节点也不要让协作伙伴陷入历史被篡改的噩梦。如果你非要在一个已被多人共享的分支上rebase建议先和所有相关同事打招呼让他们对一下reflog避免互相覆盖。4. 合并路上的拦路虎冲突识别与解决4.1 冲突到底怎么来的冲突的本质是两个分支在同一个地方做了不同的修改Git不知道该听谁的。最常见的触发场景master上有人改了文件的第30到40行你的feature也改了同一段合并时Git对比共同祖先发现两边的改动都替换了这一行无法自动决定保留哪边只能停下来请你做主。还有一些冷门但坑人的情况一个分支把文件改了个彻底另一个分支直接把这个文件删了这种“删除vs修改”的冲突要单独处理再比如两边都新增了同名文件、内容完全不一样Git也只能投降。另外哪怕改动不在同一行只要文件结构出现大面积重排也可能被识别成冲突因为Git对比的是语义块而不是简单按行号来。理解冲突来源后你会发现一个规律冲突的多少通常跟分支存在时间的长短成正比。分支活得越久master上的变化越多汇聚时碰车的概率就越大。这也是为什么很多高效团队要求你频繁地把master合并到自己分支里就是想让冲突分批解决而不是最后一次性爆发。4.2 冲突标记长什么样怎么读当冲突发生时git status会把这些文件标成“Unmerged”Git也明确提示“Automatic merge failed; fix conflicts and then commit the result”。打开冲突文件你会看到类似下面的标记以master为当前分支、合并feature为例 HEAD // master上的旧验证逻辑 let auth checkToken(user); // feature上的新验证逻辑 let auth checkTokenWithCaptcha(user, code); feature读法很简单和之间是当前分支也就是HEAD的改动和之间是另一个分支的改动。你要做的就是删掉这些标记把内容改成你希望保留的样子——可以只留master的、只留feature的也可以两边都有。改完保存文件git add标记为已解决等所有文件都解决完再提交。有一点我要特别提醒读冲突标记时千万别只盯着当前分支的代码要把标记里两边的上下文都看一遍。实际工作里我见过不少因为只看一边、把另一边的关键逻辑误删结果上线后少了一个权限判断的惨案。冲突文件里的上下文往往比冲突本身更重要删错一行标记是小事删错一段逻辑才是大事。4.3 手动处理和工具辅助怎么选小规模的冲突编辑器里手动改几乎是最快的因为你完全清楚每段代码的意图改完git add就继续。当冲突文件很多、改动量很大的时候我建议用工具辅助。git mergetool可以让Git调起你配置的可视化合并工具比如VS Code、Beyond Compare它们会把两边内容并排展示省去很多翻原文件确认上下文的时间。用工具也有几个技巧先在终端看一遍git status把冲突文件按熟悉程度分个类不熟悉的文件、涉及公共封装的文件优先处理因为它们往往是影响面最大的。还有一点解决冲突的过程中不要急着一口气改完所有文件再add而是改好一个文件就git add一个这样可以随时停下来也不容易漏。全部解决完别忘了跑一遍构建和测试冲突合并后编译不通过是常有的事这一步省不得。5. 完整案例把功能分支合并到master全程演示5.1 场景设定一个模拟项目的实际分支用一个实际的项目场景来从头过一遍流程。假设模拟项目X是一个电商平台master已经稳定运行最近的提交都集中在登录模块。这时候产品经理提了新需求增加验证码登录。于是某开发者A从master拉出一个feature分支命名规范用feature/captcha-login在分支上完成开发、测试提交了若干次现在要把代码合回master。这个场景很有代表性分支不大、改动集中在登录模块master在开发期间也进过两三个同事的提交预计会有轻微冲突正好演示完整流程。如果你手头没有现成项目可以自己建一个空仓库模拟一遍体验下来的记忆深度比看十遍文章都管用。5.2 逐步操作与命令执行从创建分支到推送合并第一步确认自己在master且是最新状态然后基于master创建分支git checkout master git pull origin master git checkout -b feature/captcha-login # 接下来在这分支上开发、提交若干次 git add . git commit -m feat: add captcha login第二步开发完成后切回master。这一步最常被忽略别偷懒切回来之前先看一眼工作区是否干净git checkout master git pull origin master第三步执行合并。因为我希望master历史里有一个明确的合并节点可以使用--no-ff同时提前料想到可能有冲突login模块被同事改过加上--no-commit先不做提交等检查完再定git merge --no-ff --no-commit feature/captcha-login如果终端提示冲突就进入第4章的方法解决冲突git add之后继续。如果一切顺利查看一下状态确认没有把不该带进来的文件带进来然后提交git status git commit第四步push到远程git push origin master到这里合并已经从本地完成并同步到远程master工作区里就是新旧逻辑融合后的完整代码。5.3 合并完成后的验证与清理推上去之后先不急着干别的。我用这几个命令做一轮验证git log --graph --oneline --decorate -n 10 git status看一眼提交图如果用的是--no-ff方式应该能看到一个明确的merge节点feature上的若干提交同时出现在它下面。确认master指向正确、工作区干净之后可以把已合并的feature分支删掉git branch -d feature/captcha-login这里有个细节只有当分支上的提交全部被合并进mastergit branch -d才会同意删除如果检测到还有没合并的提交它会拒绝并提示你用-D强制删。我建议尽量用-d而不是-D让Git帮你把关避免误删还有用的提交。6. 合并踩过的坑常见问题与排查技巧6.1 合并到了错误的分支怎么办这个场景我见过不止一次有人站在feature分支上想合并同事的分支结果脑子一热敲了git merge master把自己还没开发完的feature分支和master合并本地feature历史彻底被master主导提交图变得一团糟吓出一身冷汗。解法其实不复杂只要没push到远程、没被别人拉走完全可以用git reflog救回来。git reflog会列出HEAD移动过的每一步操作记录找到混乱发生之前最后一步正常的位置。比如在git merge master命令之前的记录记下对应的commit哈希或HEAD{n}然后执行下面的命令整个分支状态就回到操作前干干净净git reset --hard HEAD{n}熟练之后你会把reflog当作Git里的“撤销键”。这里建议不要用git reset --soft或--mixed那会把合并结果留下来该回到操作前就用--hard前提是确认工作区里的未提交内容都不重要。6.2 合并后发现代码有问题怎么回滚合并已经push到远程后再发现问题处理方式取决于这个提交是不是已经进了公共历史。进了公共历史尽量用git revert生成一个反向提交保留糊涂账做记录# 找到这次合并产生的merge commit git log --merges --oneline git revert -m 1 merge-commit-id git push origin master这里的-m 1表示保留合并提交的第一父也就是master这条主线把另一个分支的改动全部抵消。这样不会破坏历史其他同事pull下来以后依然能正常同步。如果没有push到远程只是本地合并后发现了问题那就简单多了直接用git reset --hard回到合并前。要强调的是reset会丢弃提交绝对不能用在已经push的公共分支上否则别人pull时会看到完全不同的历史。不少新手在这里栽跟头一失手把团队的分支历史清空了最后只能全员对reflog。6.3 master长期不更新合并时冲突爆炸还有一种极其常见的工作流问题feature分支从master拉出来以后开发了两个月期间master上已经合入了大量其它功能等你要合并回去时冲突文件动辄几十个改半天还没完甚至合完以后发现功能之间的交互逻辑都有问题整个merge commit变成一颗大炸弹。我的经验是分支活在本地的时长和合并的风险成正比。解决这个问题最好的办法不是练好冲突技巧而是避免产生大量冲突的条件。在feature开发期间每隔几天就主动把最新master合并进自己分支或者用rebase把变化重放上来让冲突分批出现、分批解决。这样最后合回master时通常只需要处理最近几天的冲突工作量小得多出错的概率也成倍下降。此外团队层面应该定一个规矩master分支开启保护禁止任何人直接push所有改动都走分支合并和评审。有这个规则兜底即使某人的本地master被搞乱也不会污染远程主干。6.4 合并问题速查表为了方便快速定位我把常见问题整理成一张表遇到对应症状直接对号入座症状可能原因快速处理方式合并后发现历史一片混乱在错误分支上执行了mergegit reflog找到操作前哈希git reset --hardpush失败non-fast-forward本地master落后于远程git pull origin master后再试或处理冲突合并后构建失败冲突解决时漏改或误改git status检查未合并文件逐个确认合并信息不符合规范没有按团队约定写信息合并时用-m指定或merge --no-ff后编辑合并下来的提交太多想压缩历史改用git merge --squash或rebase推送后发现合错了合并commit已进公共历史git revert -m 1撤销本地改动未提交就想合并工作区不干净带入无关文件git stash保存合并完再pop这张表我贴在很多次分享的末尾实际用起来很顺手建议你可以贴在本地备忘里。到这儿分支合并到master这件事的主要操作和坑我都写完了。最后聊一点自己的体会。在刚用Git那两年我也觉得合并就是一条命令的事后来维护的项目越来越大、协作的人越来越多才明白每一次merge背后真正考验的是你对仓库历史的理解对团队规范的尊重。在我的习惯里合并前一定把master更新到最新合并时一定用--no-ff留一个清晰的节点合并后一定看一眼提交图再收工。这套流程听起来麻烦但长久坚持下来master的历史干净、易回溯队友之间扯皮的情况也几乎绝迹。你可以先从最简单的合并开始跑通再慢慢加上这些“保险措施”等哪天不再担心合并出问题你就算真正把Git用明白了。