上一篇讲了Git的基础操作这篇来点进阶的。说实话很多人用了一年Git还是只会add、commit、push三板斧。遇到复杂场景就抓瞎。比如你在feature分支上开发到一半突然要修一个线上bug怎么办或者你想把某个commit单独挑出来放到另一个分支上怎么搞这些在机器人开发中是日常操作。面试的时候如果能讲清楚这几个命令的使用场景基本就能证明你不是纸上谈兵。git stash临时保存工作现场这是最实用的命令之一。场景是这样的你正在feature_lidar分支上写代码写到一半同事过来说线上有个紧急bug需要你修。这时候你代码改了一半不能commit因为还没写完但又不想丢掉。stash就是干这个的git stash # 把当前改动存起来 git stash save lidar解析写到一半 # 加个备注方便以后找执行完之后你的工作区就干净了回到了上次commit的状态。然后你就可以切到别的分支去修bug了。修完bug回来恢复之前存的内容git stash pop # 取出最近一次stash的内容 git stash apply # 取出但不清除更安全 git stash list # 查看所有stash git stash pop stash{2} # 取指定的stashpop和apply的区别pop取出来之后会删掉这条stash记录apply取出来但保留记录。如果你不确定会不会有冲突先用apply确认没问题再git stash drop手动删。有个坑要注意stash不会保存未跟踪的新文件就是那些还没add过的。如果你想连新文件一起存加个-u参数git stash -u。git rebase变基让提交历史更干净rebase是个争议很大的命令。用好了能让提交历史非常整洁用错了能把仓库搞得一团糟。先理解rebase在做什么。假设你在feature分支上做了3个commit同时main分支上也有新的提交。正常merge的话会产生一个合并commit历史变成分叉再合并的形状。rebase的做法不一样它把你的3个commit拔起来放到main分支最新提交的后面就像你是在最新代码基础上才开始开发的一样。git checkout feature_lidar git rebase main执行完之后你的feature分支的提交历史就是一条直线没有分叉。rebase还有一个特别实用的场景交互式rebase。你可以用它来整理自己的提交历史。git rebase -i HEAD~3 # 整理最近3个commit这会打开一个编辑器列出这3个commit你可以选择pick abc1234 添加激光雷达驱动框架 squash def5678 修复编译错误 squash ghi9012 调整代码格式squash会把后面两个commit合并到第一个里。这样你最终只提交一个干净的commit而不是三个乱七八糟的中间版本。面试的时候可以说我开发的时候习惯先随便commit最后用interactive rebase整理成一个逻辑清晰的提交再提PR。面试官一听就知道你有经验。但是有一条铁律永远不要rebase已经push到远程的公共分支。rebase会改变commit的hash值如果你rebase了main分支然后push其他所有人的本地仓库都会乱套。rebase只用于整理自己还没push的本地提交。git cherry-pick精确摘取某个提交有时候你不想合并整个分支只需要某个特定的commit。比如你在feature分支上做了5个改动其中只有第3个commit是修了一个通用bug其他4个都是功能开发。你想把这个bug修复同步到main分支但不想带那4个功能改动。cherry-pick就是干这个的git checkout main git cherry-pick abc1234 # 只摘取hash为abc1234的那个commit这个commit就被复制到了当前分支上。在机器人项目中cherry-pick有个典型场景hotfix。线上版本跑的是release分支你发现一个bug在hotfix分支上修了。修完之后既要合并到release也要同步到develop。用cherry-pick就能精确地把修复同步过去不用合并整个分支。git checkout release git cherry-pick hotfix-commit-hash git checkout develop git cherry-pick hotfix-commit-hash还有一个场景你在两个分支上都做了开发其中一个分支上的某个功能想搬到另一个分支。直接cherry-pick就行不用合并整个分支引入不相关的改动。实战场景组合实际开发中这几个命令经常组合使用。场景一开发到一半要修紧急bug。# 1. 保存当前工作 git stash -u # 2. 切到main拉最新代码 git checkout main git pull # 3. 创建hotfix分支修bug git checkout -b hotfix_critical # 4. 修完bug提交 git add . git commit -m 修复了导航模块的路径规划死循环 # 5. 合并到main git checkout main git merge hotfix_critical # 6. 回到原来的feature分支恢复工作 git checkout feature_lidar git stash pop场景二整理提交历史后提PR。# 1. 在feature分支上开发做了很多零碎的commit # 2. 开发完了用interactive rebase整理 git rebase -i HEAD~5 # 3. 编辑器里把相关的commit squash到一起 # 4. rebase到最新的main上 git fetch origin git rebase origin/main # 5. push到远程提PR git push origin feature_lidar场景三cherry-pick配合rebase。# 你在feature分支上发现了一个通用bug并修复了 # 但feature分支还没开发完不想合并 # 先把修复摘到main上 git checkout main git cherry-pick feature-commit-hash # 然后回到feature分支继续开发 git checkout feature_lidar面试中怎么聊这些进阶操作面试官一般不会让你现场敲rebase命令但会问场景题。比如你开发到一半需要切分支修bug怎么处理这时候你说stash面试官就知道你真正用过。再比如你的提交历史很乱怎么办你说interactive rebase加squash把零碎commit整理成逻辑完整的提交。这比说删了重新提交强一百倍。关键是要讲清楚为什么这么做而不是仅仅说怎么做。命令谁都能查到但理解在什么场景下用什么命令这才是经验。Git高级命令的实战场景rebase和merge的区别是面试高频题。简单说merge保留完整的分支历史rebase让历史变成线性的。实际项目中个人分支用rebase保持整洁公共分支用merge保留记录。cherry-pick适合把某个commit单独挑出来应用到另一个分支比如紧急修复bug时。stash则是临时保存工作区的利器切换分支前不用提交就能暂存改动。给你的建议先把stash用熟。这是最安全、最没有争议的命令用错了也不会搞乱仓库。日常开发中stash的使用频率非常高养成习惯。rebase建议先在本地练。自己建两个分支随便提交几个commit练习rebase操作。等理解了它的工作原理再在真实项目里用。记住那条铁律不rebase公共分支。cherry-pick用得相对少一些但在特定场景下特别好用。遇到只想同步某个commit的需求时第一时间想到它。Git这东西光看文章学不会。得多用多踩坑踩完了再回头看就理解了。上一篇第98篇 Git基础——add/commit/push/branch的正确使用姿势下一篇预告第100篇 Git团队协作——分支策略、冲突解决和Code Review流程