1. 分支纠结现场：为什么大家的git乱成一锅粥1.1 一个真实困扰：代码怎么又“丢”了上个月某天下午，A同学在公司群里发了一句“我改的代码怎么没了”，紧接着截图里是一堆红色的冲突标记。那一刻我就知道，这不是代码丢了，而是git使用习惯出了大问题。后来我一问，发现团队成员对git的认知基本停留在“git add、git commit、git push”这三板斧上，所有人都在同一套分支上互相覆盖，主分支的提交记录乱得像被洗衣机搅过一样。这种场景太常见了。工具本身没有问题，问题在于多数人把git当成“网盘高级版”，只用来存文件、拉文件，却完全忽略了它真正的价值——版本协作模型。如果你告诉我“我用git用了三年”，然后打开提交记录发现每天都是“update”“修改”“fix bug”这种信息，再往下看所有提交标签都打在同一个分支上，那我只能说你其实根本没用过git。1.2 从“记录版本”到“管理协作”的思维转换git和一众网盘工具最本质的区别，不是“能回滚”，而是“能并行”。网盘也能回滚，但它做不到让几十个人同时在自己的沙盒里工作，然后像织布一样把大家的东西安全地交织在一起。我经常拿“多人合写一本书”打比方：每个人手里都有一份草稿，大家都在自己那份草稿上写写画画，互不影响。写完以后，需要有人把大家的修改汇总成一版新的草稿。git里的“分支”就是这些各自的草稿，“合并”就是汇总，“冲突”就是两个人改了同一段话但改法不一致，需要人来裁决。想通这个逻辑，再看git就豁然开朗了：分支不是用来装最新的代码的，而是用来隔离工作状态的；commit记录不是流水账，而是这本合写之书的修订说明；rebase、cherry-pick、reset这些命令，则是整理修订说明和打捞错稿的工具。1.3 分支模型并非越复杂越好网上能搜到各种分支模型，什么主分支、开发分支、功能分支、发布分支、热修复分支，一套接一套。我也见过有的团队把分支模型画成地铁线路图，新人入职第一周光记分支定义就晕头转向。实际经验告诉我，越是小团队，分支模型越要精简。超过十个人的团队，其实“主分支 + 功能分支 + 修复分支”就非常够用。注意，这里说的是“分支角色”，不是说只能有三个分支。你不断开新功能分支没问题，但每个分支的角色要固定：主分支永远是稳定可发的，功能分支永远是从主分支拉出来的，修复分支只处理线上紧急问题。角色一旦混乱，git的操作难度会指数级上升。这也是为什么我建议团队里至少要有一个人专门把关git的使用规范，而不是让每个人按自己的习惯自由发挥。工具没有纪律，再好的工具也会变成灾难现场。2. commit是怎么“长大”的：从写流水账到写简报2.1 什么样的commit记录才叫“可读”不少开发者把commit当成“保存游戏进度”，隔几分钟保存一次，觉得“写清楚了太麻烦”。但如果你是那个接手别人代码的人，看到一串“update”“fix”“test”时，内心一定是在骂人的。提交信息写得好不好，不取决于写得多不多，而取决于读的人能不能快速知道“这个改动想解决什么问题”。我的习惯是遵循“动词 + 对象 + 原因”的结构，例如“fix: 修复登录接口忘记传session导致超时”，而不是“修改bug”。如果一次提交涉及多个目的，那就拆分成多个commit，不要硬塞进一个提交里。短小的、语义清晰的commit，是后续rebase、cherry-pick、bisect排查问题的地基。2.2 rebase --interactive整理历史的三板斧说到整理commit，最高频的命令就是git rebase -i HEAD~n，这个-i是interactive的缩写，意思是交互式rebase。我曾经用这个命令把同事提交的三十多个“杂碎”commit压缩成三个清晰的版本，整个提交历史从一大坨变成三小块，看起来赏心悦目。具体怎么做并不复杂。假设你在功能分支上，输入git rebase -i HEAD~5，会弹出一个编辑器，列出最近5条commit。每条commit前有pick关键词，你可以把它改成：pick：保留这个提交，什么都不改；reword：保留提交内容，但重写提交信息；squash：把当前提交和上一个提交合并，同时可以合并提交信息。我最常用的是squash。一个小功能开发了三天，期间提交了五六次“中间状态”，可以直接用squash把它们全部压成一个commit，并重新写一条清晰的说明。这样整个功能分支的提交历史会非常整洁。2.3 实战演示一把带“提交信息”的强迫症整理假设我有一个功能分支，上面有5条commit，我想把它们整理成2条：一条是“feat: 新增商品列表接口”，另一条是“fix: 修复列表分页参数为空的边界问题”。我可以执行：git rebase -i HEAD~5然后在编辑器里把对应的几条pick改成squash，保存退出。之后git会提示我合并提交信息，我再把描述简化成清晰的一句话。这里有个极容易踩的坑：整理的是尚未推送到远端的分支。如果分支已经push到远端，并且别人已经在用，就不要随便rebase去改历史，否则下次push时会跟远端冲突，轻则重新拉取再合并，重则直接搞乱队友的本地分支。我见过有人对公共分支执行rebase -i，结果所有人都在喊“我的代码不见了”，其实代码没丢，是远端历史被改写，造成各本地仓库的分叉。3. merge与rebase的世纪对决：合并也能不伤和气3.1 冲突到底是怎么产生的很多新人以为冲突是“代码坏了”，其实冲突本质上只是“git拿不定主意了”。当两个人修改了同一行代码，或者一个人改了文件内容，另一个人删除了这个文件时，git不知道你到底想保留谁的版本，所以它把问题抛给你。冲突不可怕，可怕的是看到冲突后第一反应是硬着头皮去删别人的代码。我见过有人为了“消除冲突”，直接把整个文件改成自己的版本再提交，其他人的改动直接覆盖没了。这种做法比冲突本身危险一百倍。3.2 我们踩过的坑：merge得一发不可收拾以前我们团队习惯用git merge合并分支。merge的好处是保留分支分叉的时间线，看得到“从哪里合并到哪”，但坏处是历史记录里会出现大量的“Merge branch ‘xxx’ into ‘yyy’”节点，加上提交又多又乱，最后整张提交图看起来像一张蜘蛛网。有一次我试图用git log --graph梳理上线前谁改了什么，结果看了差不多十分钟也没看清主线。当时我就下定决心，团队内部统一改用rebase方式合并功能分支。3.3 rebase之后出现“鬼影”冲突的排查链路git rebase不是银弹，它同样会产生冲突，而且有时候会产生一种让新手很崩溃的“重复冲突”。所谓“重复冲突”，是你解决了一次冲突后，rebase继续往下重放commit时，又遇到一模一样的冲突。这是因为原本rebase是一条条把commit按顺序搬到新基线上去的，每次搬移都会重新对照一遍最近的改动内容。遇到这种情况，我的排查链路是：先看清楚当前rebase进行到第几步，git status会明确显示哪个文件冲突；用git diff对比当前文件和冲突标记里的两段内容，判断到底要保留哪个；完成一次解决后，执行git add <文件>并git rebase --continue，让rebase继续；如果再遇到相同文件的相同冲突，不要慌，重复第三步，因为这是rebase机制导致的正常现象。还有一个更聪明的思路：如果你在一个功能分支上长时间没同步主分支，靠rebase容易一路撞车，这时候不如先git merge origin/main把主分支拉回功能分支一次，解决完合并冲突，再继续个性化开发。这样能把“未来会发生的冲突”提前一次性还清。4. 后悔药加时光机：reflog、reset与cherry-pick的救场指南4.1 手滑删了分支，reflog如何捞回来要问我git里哪个命令最容易被低估，我的答案一定是git reflog。有人把它叫作“后悔药”，因为它记录的是你本地仓库每一次HEAD指针的变动，哪怕那个分支已经被删了，只要reflog里还有记录，你就可以找回它的commit哈希值。有一次笔者自己就干过这事，大概情形是：旁边同事A让我帮忙清理一个废弃分支，我一边聊天一边操作，一不留神把一个还有未合并内容的分支删了。等我反应过来的瞬间，心都凉了。但用git reflog一看，删除前HEAD指向的commit哈希还在，直接执行：git branch 恢复分支名 <commit哈希>分支就神奇地回来了。注意，reflog不是永久保存的，默认会在一段时间后清理掉，具体时间取决于gc.reflogExpire配置。所以一旦发现自己误删，越早越好，别拖到第二天。4.2 reset三兄弟的适用边界git reset有三个模式：--soft、--mixed、--hard。很多人只知道--hard，动不动就git reset --hard，结果直接把工作区的改动全部冲掉了，再哭天喊地找我要数据。这三个模式其实对应三个层面：--soft：只动HEAD，改动还暂存在暂存区，适合“我想重新提交，但不想丢失已经add的内容”；--mixed（默认）：动了HEAD和暂存区，工作区文件内容不变，适合“我不小心add了一个不该add的文件，想退回去再重新add”；--hard：动了HEAD、暂存区和工作区，彻底回到某个状态，适合“我自己已经确定不要这些改动了”。我的建议是：除非你百分百确定要放弃所有改动，否则永远不要裸用--hard。如果实在要硬重置，先git stash或git branch 备份分支把当前状态藏起来，给自己留条后路。4.3 cherry-pick：把别人一个commit“偷”过来有朋友问过我：“我只需要把另一个分支上的某个提交弄过来，又不想整个合并，怎么办？”答案就是git cherry-pick。举个例子，某同事在开发分支上修了一个bug，commit信息是“fix: 修复订单金额精度问题”，但你的功能分支不想把整个开发分支的乱七八糟历史都合过来，只想拿这个修复。你只需要在功能分支上执行：git cherry-pick <commit的哈希>就能把这个commit“复制”过来。如果有冲突，解决完继续git cherry-pick --continue。可以用git log --oneline查看他的commit哈希。cherry-pick是现实协作里特别实用的命令，因为它完美对应了“我需要你的修改，但不想被你的历史拖累”这个场景。唯一值得提醒的是，cherry-pick会生成一个全新的commit，哈希不同，所以不要指望用git diff去比较两个分支时它们是“同一个东西”，内容相同但身份不同，这是正常现象。5. 一套让团队少吵架的git使用简报5.1 分支命名与提交流程：最少但够用的约定讲完了一堆实操命令，最后想聊聊那些“不写在命令手册里”的东西。git用得好不好，一半在于命令熟练，另一半在于团队约定。没有约定，每个人都会用自己的方式工作。我给不少团队处理过这类问题，最后沉淀下来的一套最简约定是：主分支：main，永远保持可以发布的稳定状态；功能分支：feature/<功能名称>，从main拉出，开发完成后合并回main；修复分支：fix/<问题描述>，从main拉出，处理完立刻合并回main并删除分支；不在main上直接提交代码，所有变更都走分支合并。这四条约定看起来简单，但能解决80%的分支混乱问题。新人在熟悉git的第一周只需要记这四条规则就行。5.2 开发、测试、主干的流转顺序我们团队内部的工作流是：开发者在功能分支上干活，本地多提交几次没关系；功能完成并自测通过后，执行git rebase main确保分支基于最新主干的代码，然后再把功能分支推向远端；接着做一次git merge --no-ff feature/xxx合入测试分支，--no-ff的意思是不要“快进合并”，保留一个合并节点，方便测试人员知道“这个测试环境包含哪些功能”。测试通过后，再由专人合入main。合入main的操作本身很简单，但测试和合入必须分离，否则“顺手合入”会让主分支的稳定性大打折扣。5.3 个人心得：如何在新人入职时快速训练git手感最后分享一个我屡试不爽的训练方法。新人入职后，我不让他们先看手册，而是让他们在自己的本地仓库里重复一组动作：创建一个分支，提交几分钟，再用git reflog删掉分支找回来，再用git rebase -i把多个提交压成一个，再模拟一次冲突并解决。看起来像是惩罚人的小练习，但实际上一天之内就把整个git操作的肌肉记忆练出来了，后面进入真实项目协作基本不会犯错。说到底，git使用的门槛不在语法，而在心智模型。把分支、历史、合并想成协作的棋局，把命令当成落子的手势，自然每一步都稳。我自己也是从“天天用git reset --hard擦屁股”的阶段走过来的，这种事情见得多了，就更相信“纪律 + 理解”比“背命令 + 硬搞”更重要。
1. 分支纠结现场：为什么大家的git乱成一锅粥1.1 一个真实困扰：代码怎么又“丢”了上个月某天下午，A同学在公司群里发了一句“我改的代码怎么没了”，紧接着截图里是一堆红色的冲突标记。那一刻我就知道，这不是代码丢了，而是git使用习惯出了大问题。后来我一问，发现团队成员对git的认知基本停留在“git add、git commit、git push”这三板斧上，所有人都在同一套分支上互相覆盖，主分支的提交记录乱得像被洗衣机搅过一样。这种场景太常见了。工具本身没有问题，问题在于多数人把git当成“网盘高级版”，只用来存文件、拉文件，却完全忽略了它真正的价值——版本协作模型。如果你告诉我“我用git用了三年”，然后打开提交记录发现每天都是“update”“修改”“fix bug”这种信息，再往下看所有提交标签都打在同一个分支上，那我只能说你其实根本没用过git。1.2 从“记录版本”到“管理协作”的思维转换git和一众网盘工具最本质的区别，不是“能回滚”，而是“能并行”。网盘也能回滚，但它做不到让几十个人同时在自己的沙盒里工作，然后像织布一样把大家的东西安全地交织在一起。我经常拿“多人合写一本书”打比方：每个人手里都有一份草稿，大家都在自己那份草稿上写写画画，互不影响。写完以后，需要有人把大家的修改汇总成一版新的草稿。git里的“分支”就是这些各自的草稿，“合并”就是汇总，“冲突”就是两个人改了同一段话但改法不一致，需要人来裁决。想通这个逻辑，再看git就豁然开朗了：分支不是用来装最新的代码的，而是用来隔离工作状态的；commit记录不是流水账，而是这本合写之书的修订说明；rebase、cherry-pick、reset这些命令，则是整理修订说明和打捞错稿的工具。1.3 分支模型并非越复杂越好网上能搜到各种分支模型，什么主分支、开发分支、功能分支、发布分支、热修复分支，一套接一套。我也见过有的团队把分支模型画成地铁线路图，新人入职第一周光记分支定义就晕头转向。实际经验告诉我，越是小团队，分支模型越要精简。超过十个人的团队，其实“主分支 + 功能分支 + 修复分支”就非常够用。注意，这里说的是“分支角色”，不是说只能有三个分支。你不断开新功能分支没问题，但每个分支的角色要固定：主分支永远是稳定可发的，功能分支永远是从主分支拉出来的，修复分支只处理线上紧急问题。角色一旦混乱，git的操作难度会指数级上升。这也是为什么我建议团队里至少要有一个人专门把关git的使用规范，而不是让每个人按自己的习惯自由发挥。工具没有纪律，再好的工具也会变成灾难现场。2. commit是怎么“长大”的：从写流水账到写简报2.1 什么样的commit记录才叫“可读”不少开发者把commit当成“保存游戏进度”，隔几分钟保存一次，觉得“写清楚了太麻烦”。但如果你是那个接手别人代码的人，看到一串“update”“fix”“test”时，内心一定是在骂人的。提交信息写得好不好，不取决于写得多不多，而取决于读的人能不能快速知道“这个改动想解决什么问题”。我的习惯是遵循“动词 + 对象 + 原因”的结构，例如“fix: 修复登录接口忘记传session导致超时”，而不是“修改bug”。如果一次提交涉及多个目的，那就拆分成多个commit，不要硬塞进一个提交里。短小的、语义清晰的commit，是后续rebase、cherry-pick、bisect排查问题的地基。2.2 rebase --interactive整理历史的三板斧说到整理commit，最高频的命令就是git rebase -i HEAD~n，这个-i是interactive的缩写，意思是交互式rebase。我曾经用这个命令把同事提交的三十多个“杂碎”commit压缩成三个清晰的版本，整个提交历史从一大坨变成三小块，看起来赏心悦目。具体怎么做并不复杂。假设你在功能分支上，输入git rebase -i HEAD~5，会弹出一个编辑器，列出最近5条commit。每条commit前有pick关键词，你可以把它改成：pick：保留这个提交，什么都不改；reword：保留提交内容，但重写提交信息；squash：把当前提交和上一个提交合并，同时可以合并提交信息。我最常用的是squash。一个小功能开发了三天，期间提交了五六次“中间状态”，可以直接用squash把它们全部压成一个commit，并重新写一条清晰的说明。这样整个功能分支的提交历史会非常整洁。2.3 实战演示一把带“提交信息”的强迫症整理假设我有一个功能分支，上面有5条commit，我想把它们整理成2条：一条是“feat: 新增商品列表接口”，另一条是“fix: 修复列表分页参数为空的边界问题”。我可以执行：git rebase -i HEAD~5然后在编辑器里把对应的几条pick改成squash，保存退出。之后git会提示我合并提交信息，我再把描述简化成清晰的一句话。这里有个极容易踩的坑：整理的是尚未推送到远端的分支。如果分支已经push到远端，并且别人已经在用，就不要随便rebase去改历史，否则下次push时会跟远端冲突，轻则重新拉取再合并，重则直接搞乱队友的本地分支。我见过有人对公共分支执行rebase -i，结果所有人都在喊“我的代码不见了”，其实代码没丢，是远端历史被改写，造成各本地仓库的分叉。3. merge与rebase的世纪对决：合并也能不伤和气3.1 冲突到底是怎么产生的很多新人以为冲突是“代码坏了”，其实冲突本质上只是“git拿不定主意了”。当两个人修改了同一行代码，或者一个人改了文件内容，另一个人删除了这个文件时，git不知道你到底想保留谁的版本，所以它把问题抛给你。冲突不可怕，可怕的是看到冲突后第一反应是硬着头皮去删别人的代码。我见过有人为了“消除冲突”，直接把整个文件改成自己的版本再提交，其他人的改动直接覆盖没了。这种做法比冲突本身危险一百倍。3.2 我们踩过的坑：merge得一发不可收拾以前我们团队习惯用git merge合并分支。merge的好处是保留分支分叉的时间线，看得到“从哪里合并到哪”，但坏处是历史记录里会出现大量的“Merge branch ‘xxx’ into ‘yyy’”节点，加上提交又多又乱，最后整张提交图看起来像一张蜘蛛网。有一次我试图用git log --graph梳理上线前谁改了什么，结果看了差不多十分钟也没看清主线。当时我就下定决心，团队内部统一改用rebase方式合并功能分支。3.3 rebase之后出现“鬼影”冲突的排查链路git rebase不是银弹，它同样会产生冲突，而且有时候会产生一种让新手很崩溃的“重复冲突”。所谓“重复冲突”，是你解决了一次冲突后，rebase继续往下重放commit时，又遇到一模一样的冲突。这是因为原本rebase是一条条把commit按顺序搬到新基线上去的，每次搬移都会重新对照一遍最近的改动内容。遇到这种情况，我的排查链路是：先看清楚当前rebase进行到第几步，git status会明确显示哪个文件冲突；用git diff对比当前文件和冲突标记里的两段内容，判断到底要保留哪个；完成一次解决后，执行git add <文件>并git rebase --continue，让rebase继续；如果再遇到相同文件的相同冲突，不要慌，重复第三步，因为这是rebase机制导致的正常现象。还有一个更聪明的思路：如果你在一个功能分支上长时间没同步主分支，靠rebase容易一路撞车，这时候不如先git merge origin/main把主分支拉回功能分支一次，解决完合并冲突，再继续个性化开发。这样能把“未来会发生的冲突”提前一次性还清。4. 后悔药加时光机：reflog、reset与cherry-pick的救场指南4.1 手滑删了分支，reflog如何捞回来要问我git里哪个命令最容易被低估，我的答案一定是git reflog。有人把它叫作“后悔药”，因为它记录的是你本地仓库每一次HEAD指针的变动，哪怕那个分支已经被删了，只要reflog里还有记录，你就可以找回它的commit哈希值。有一次笔者自己就干过这事，大概情形是：旁边同事A让我帮忙清理一个废弃分支，我一边聊天一边操作，一不留神把一个还有未合并内容的分支删了。等我反应过来的瞬间，心都凉了。但用git reflog一看，删除前HEAD指向的commit哈希还在，直接执行：git branch 恢复分支名 <commit哈希>分支就神奇地回来了。注意，reflog不是永久保存的，默认会在一段时间后清理掉，具体时间取决于gc.reflogExpire配置。所以一旦发现自己误删，越早越好，别拖到第二天。4.2 reset三兄弟的适用边界git reset有三个模式：--soft、--mixed、--hard。很多人只知道--hard，动不动就git reset --hard，结果直接把工作区的改动全部冲掉了，再哭天喊地找我要数据。这三个模式其实对应三个层面：--soft：只动HEAD，改动还暂存在暂存区，适合“我想重新提交，但不想丢失已经add的内容”；--mixed（默认）：动了HEAD和暂存区，工作区文件内容不变，适合“我不小心add了一个不该add的文件，想退回去再重新add”；--hard：动了HEAD、暂存区和工作区，彻底回到某个状态，适合“我自己已经确定不要这些改动了”。我的建议是：除非你百分百确定要放弃所有改动，否则永远不要裸用--hard。如果实在要硬重置，先git stash或git branch 备份分支把当前状态藏起来，给自己留条后路。4.3 cherry-pick：把别人一个commit“偷”过来有朋友问过我：“我只需要把另一个分支上的某个提交弄过来，又不想整个合并，怎么办？”答案就是git cherry-pick。举个例子，某同事在开发分支上修了一个bug，commit信息是“fix: 修复订单金额精度问题”，但你的功能分支不想把整个开发分支的乱七八糟历史都合过来，只想拿这个修复。你只需要在功能分支上执行：git cherry-pick <commit的哈希>就能把这个commit“复制”过来。如果有冲突，解决完继续git cherry-pick --continue。可以用git log --oneline查看他的commit哈希。cherry-pick是现实协作里特别实用的命令，因为它完美对应了“我需要你的修改，但不想被你的历史拖累”这个场景。唯一值得提醒的是，cherry-pick会生成一个全新的commit，哈希不同，所以不要指望用git diff去比较两个分支时它们是“同一个东西”，内容相同但身份不同，这是正常现象。5. 一套让团队少吵架的git使用简报5.1 分支命名与提交流程：最少但够用的约定讲完了一堆实操命令，最后想聊聊那些“不写在命令手册里”的东西。git用得好不好，一半在于命令熟练，另一半在于团队约定。没有约定，每个人都会用自己的方式工作。我给不少团队处理过这类问题，最后沉淀下来的一套最简约定是：主分支：main，永远保持可以发布的稳定状态；功能分支：feature/<功能名称>，从main拉出，开发完成后合并回main；修复分支：fix/<问题描述>，从main拉出，处理完立刻合并回main并删除分支；不在main上直接提交代码，所有变更都走分支合并。这四条约定看起来简单，但能解决80%的分支混乱问题。新人在熟悉git的第一周只需要记这四条规则就行。5.2 开发、测试、主干的流转顺序我们团队内部的工作流是：开发者在功能分支上干活，本地多提交几次没关系；功能完成并自测通过后，执行git rebase main确保分支基于最新主干的代码，然后再把功能分支推向远端；接着做一次git merge --no-ff feature/xxx合入测试分支，--no-ff的意思是不要“快进合并”，保留一个合并节点，方便测试人员知道“这个测试环境包含哪些功能”。测试通过后，再由专人合入main。合入main的操作本身很简单，但测试和合入必须分离，否则“顺手合入”会让主分支的稳定性大打折扣。5.3 个人心得：如何在新人入职时快速训练git手感最后分享一个我屡试不爽的训练方法。新人入职后，我不让他们先看手册，而是让他们在自己的本地仓库里重复一组动作：创建一个分支，提交几分钟，再用git reflog删掉分支找回来，再用git rebase -i把多个提交压成一个，再模拟一次冲突并解决。看起来像是惩罚人的小练习，但实际上一天之内就把整个git操作的肌肉记忆练出来了，后面进入真实项目协作基本不会犯错。说到底，git使用的门槛不在语法，而在心智模型。把分支、历史、合并想成协作的棋局，把命令当成落子的手势，自然每一步都稳。我自己也是从“天天用git reset --hard擦屁股”的阶段走过来的，这种事情见得多了，就更相信“纪律 + 理解”比“背命令 + 硬搞”更重要。