最近在技术群里看到不少刚入行的朋友吐槽“系统上线了产品经理又塞过来一个要开发两个月的大需求但线上时不时还得修Bug这代码我都不敢乱动生怕把正在跑的系统改崩了。”其实这种“既要开发新大陆又要保卫旧家园”的窘境正是版本控制系统的核心痛点。如果你还在用复制文件夹、加后缀_final、_final2的方式来管理代码那你真的需要好好了解一下Git分支了。今天我们就来深入聊一聊Git分支的本质、操作流程以及当代码冲突发生时如何优雅地“化干戈为玉帛”。为什么需要分支先来聊聊“平行宇宙”想象一下你正在开发一款APP目前线上运行的是V1.0版本稳定且用户量大。现在产品经理提了一个V2.0的大需求预计工期两个月。同时V1.0偶尔会出现Bug需要紧急修复。如果没有分支你的工作区会变成一场灾难改V2.0的代码时突然要修V1.0的Bug你只能把写了一半的代码注释掉或者小心翼翼地备份。不仅效率低下还极易出错。而Git分支就像是给你的项目开启了“平行宇宙”模式。主分支master/main相当于“生产环境”这里的代码永远是稳定、可运行的。Bug修复分支hot-fix当线上出问题时从主分支拉出一个“急救宇宙”在这里修好Bug再合并回去。功能开发分支feature从主分支拉出另一个“研发宇宙”在这里大刀阔斧地开发新功能无论怎么折腾都不会影响正在运行的主分支。这就是分支的魅力让你的工作从开发主线上分离开来互不干扰。打破误解master分支其实并不特殊很多初学者认为master或main分支是“神”一样的存在具有特殊权限。其实不然在Git的世界里master分支和hot-fix、dev分支没有任何区别它们都只是一个指针。为什么我们会有master仅仅是因为当你执行git init初始化仓库时Git默认帮你创建了这个名字的分支。就像新生儿出生默认有个名字叫“宝宝”一样大多数人都懒得改它久而久之就成了默认习惯。深入浅出分支操作全流程为了让大家更直观地理解我们模拟一个真实的开发场景。1. 查看与创建分支首先我们要知道当前仓库里有哪些分支。git branch -v如果是新仓库你只会看到一个master分支后面跟着一串commit id和注释。现在假设我们要修复一个紧急的Bug我们创建一个名为hot-fix的分支git branch hot-fix此时再次查看你会发现hot-fix和master指向的commit id是完全相同的。为什么因为hot-fix是从master这一刻的状态“克隆”出来的一个副本指针。2. 分支的本质移动的指针随着开发的进行我们要理解Git的核心原理分支本质上就是指向某个提交记录commit的可移动指针。当我们修改master分支上的代码并提交master指针就会向前移动到最新的提交。当我们切换分支时Git实际上只是在移动HEAD指针的位置。如果HEAD指向master我们就在master分支上如果HEAD指向hot-fix我们就在hot-fix分支上。3. 切分场景各自为战假设我们在master分支上修改了hello.txt并提交了第四次修改Forth Commit。此时master指向了最新的提交74d3939hot-fix仍然指向最初的提交8ca80d7这时两个分支已经“分道扬镳”了彼此不知道对方发生了什么。接着我们切换回hot-fix分支git checkout hot-fix在hot-fix分支里我们修改hello.txt将内容改为“hot-fix version”并提交。这时hot-fix指针也向前移动到了新的提交aab9100。注意此时master和hot-fix已经是两套独立的代码了互不干扰。高潮迭起合并与冲突当我们修完了Bug需要把hot-fix的改动同步到master上以便发布新版本。这就是合并。首先切换回master分支git checkout master然后执行合并命令git merge hot-fix最令人头疼的“冲突”合并的过程并不总是风平浪静的。如果master分支在创建hot-fix之后没有任何改动那么合并会非常顺利Git直接让master指针指向hot-fix的位置这叫“快进模式”。但现实往往很骨感。如果master分支在你修Bug的这段时间里也修改了同一份文件的同一行代码那么Git就懵了它不知道该保留master上的修改还是hot-fix上的修改。这时Git会暂停合并并告诉你“CONFLICT”。命令行状态会变成MERGING。打开冲突的文件你会看到这样的标记 HEAD hello atguigu! master hello atguigu! hot-fix hot-fix hello atguigu! HEAD 到 之间的内容是当前所在分支master的代码。 到 hot-fix 之间的内容是你要合并过来的分支hot-fix的代码。冲突的本质Git无法替你做决定必须由你——开发者来裁决。解决冲突的“三板斧”既然冲突不可避免那么如何优雅地解决它第一步手动编辑文件打开冲突文件删除那些、、的标记。保留你最终想要的那行代码。你可以保留master的也可以保留hot-fix的甚至可以两行都保留或者改成一句全新的代码。比如我们最终决定改成hello atguigu! master hot-fix hello atguigu!第二步标记为已解决告诉Git冲突我已经摆平了把文件添加到暂存区git add hello.txt第三步提交合并注意这里的提交不能带文件名。因为合并操作本身就是一个完整的提交代表你完成了合并工作。git commit -m merge hot-fix提交后MERGING状态消失分支恢复正常。至此冲突完美解决。进阶心法如何避免无谓的冲突冲突虽然可以解决但能避免最好。毕竟在团队协作中频繁的冲突会消耗大量的沟通成本。各司其职分模块开发尽量避免多个开发者在同一个分支、同一个文件的同一段代码上工作。如果前端、后端、数据库脚本都由不同的人维护自然相安无事。但在一个项目中配置类、工具类往往是冲突的重灾区。核心代码专人维护对于配置文件和公共工具类尽量由一个人或者一个核心小组来维护。其他人如果需要修改先沟通或者等维护者修改好后其他人再通过拉取pull来更新而不是自己直接改。千万不要在master分支上写代码这是一个基本素养。master分支应该只作为发布分支。所有的开发都应该在独立的feature分支上进行所有的Bug修复都应该在hot-fix分支上进行。保持master的“神圣纯洁”能极大减少合并时的痛苦。频繁同步拒绝“孤岛”不要在自己的分支上开发一个月不推送到远程也不拉取主干的更新。频繁地从master拉取最新代码合并到自己的分支可以让小的冲突及时暴露并解决避免最后合并时堆积成一座“冲突大山”。总结Git分支不仅仅是命令行里的几个单词它更是一种并行开发的哲学。它让你在面对产品经理的“奇思妙想”时能从容地拉出一个独立分支安心开发它让你在面对线上突发Bug时能快速响应而不必担心覆盖了正在开发的新功能。从本质上讲分支只是可移动的指针而HEAD决定了我们身处哪个“宇宙”。真正让Git强大的是它允许我们在不同的“宇宙”间自由穿梭、合并。当你熟练掌握了分支的查看、创建、切换、合并以及最重要的冲突解决技巧后你就再也不会害怕代码管理。相反你会爱上这种秩序井然的开发节奏。记住好的代码是管理出来的而不是堆砌出来的。掌握了分支你就掌握了团队协作的“任督二脉”。希望今天的分享能帮你打通这一关