Git Rebase 使用指南把提交历史拉直的魔法附一次真实变基实录前言同样是合并分支merge是原地打结rebase是拆了重排。本文先用一张图、几句话讲清 rebase 的本质然后用我最近一次真实的生产实操把功能分支变基到最新的develop/machine_S115带你走一遍完整流程——包括为什么最后要用--force-with-lease强推。目录一、一句话理解 Rebase变基二、一张图看懂merge vs rebase三、实战案例一次完整的变基实录四、终端输出逐行解读五、进阶交互式 rebase 整理提交六、黄金法则别动公共历史七、总结一、一句话理解 Rebase变基你的功能分支是从main某个旧点上长出来的。rebase 就是把你的提交一个个摘下来接到目标分支的最新顶端重新提交一遍——基底变了所以叫变基。它和 merge 的本质区别mergerebase做法两个分支原地汇合产生一个合并提交摘下你的提交重放到目标分支最新处历史保留分叉的真实形状重写成一条直线提交 hash不变全部改变重放生成的都是新提交适用公共分支合并私有分支同步主干一句话rebase 后你的分支看起来就像你从最新代码上一次开发出来的。二、一张图看懂merge vs rebase【merge原地汇合】 main C1 ── C2 ────────── C3 ──── M \ ╱ feature F1 ── F2 ──────── M 合并提交有两个父节点 历史保留分叉的真实形状 【rebase摘下重放】 main C1 ── C2 ── C3 ── F1 ── F2 ╲ F1 ── F2 虚线旧提交被重写丢弃 你的提交被搬到 main 顶端历史变成一条直线merge 像把两条绳子打了个结rebase 像把你的绳子拆下来接在主绳末端——事后看全程只有一条绳。三、实战案例一次完整的变基实录3.1 想要干嘛真实场景我手上两个分支develop/machine_S115同事维护的主开发分支一直有新更新feature/emerge_stop_secon_recover我的功能分支但基于旧代码需求继续在 feature 分支上开发但又不想丢掉 S115 的新更新。与其等最后合并时面对一堆冲突不如现在就把 feature 分支变基到云端最新的 S115 上。3.2 动手前的自查基准选云端的origin/develop/machine_S115——不用先切到它fetch 之后远程镜像就是最新少两次分支切换git status确认工作区干净——有未提交改动先 commit 或 stash心里有数完成后推送要--force-with-lease——因为 rebase 会重写历史3.3 完整操作终端实录# 0) 自查工作区必须干净$gitstatus On branch feature/emerge_stop_secon_recover Your branch is up todatewithorigin/feature/emerge_stop_secon_recover.nothing to commit, working tree clean# 1) 一步同步云端所有分支不用切分支、不动本地代码$gitfetch origin# 2) 变基把我的提交重放到云端 S115 最新处$gitrebase origin/develop/machine_S115 Successfully rebased and updated refs/heads/feature/emerge_stop_secon_recover.# 3) 历史被重写普通 push 会被拒——用安全强推$gitpush --force-with-lease origin feature/emerge_stop_secon_recover 2f36c33...adcf74c feature/emerge_stop_secon_recover -feature/emerge_stop_secon_recover(forced update)就这三条命令一次成功、零冲突收工。四、终端输出逐行解读终端输出怎么读它nothing to commit, working tree clean没有未提交改动变基前提满足可以动手git fetch origin无任何输出正常fetch 静默完成所有origin/xxx镜像已更新到云端最新Successfully rebased and updated ...一次成功、零冲突——历史已重写成一条直线 2f36c33...adcf74c ... (forced update)强推成功和forced update表明云端指针被移到新历史上remote: Create pull request ...Bitbucket 主动给出 PR 链接——合并回 S115 时点它走正常审查4.1 为什么用 --force-with-lease 而不是 --force--force是无脑覆盖云端有别人的新提交也会被抹掉同事的成果直接消失--force-with-lease会先检查云端还是我上次看到的那个版本吗不是就拒绝推送。本次变基后云端 feature 分支只有我自己在用所以它能安全通过。养成习惯能用--force-with-lease就永远别用--force。4.2 收尾必做编译验证变基后的代码是最新基底 我的改动的混合体接口变更、宏被删这类问题只有编译能暴露。所以我最后一步是立刻编译一遍固件确认通过再点 remote 给出的 PR 链接发起合并请求。这一步经常被忽略rebase 成功只代表 git 层面无冲突不代表代码逻辑层面兼容。尤其是嵌入式/MCU 项目基底更新后外设驱动接口变了是常事。五、黄金法则别动公共历史rebase 会重写提交历史。如果对已经 push 到公共分支如main、共享分支的提交做 rebase别人 pull 下来会撞出大量重复冲突团队历史直接乱套。历史一旦公开就是团队契约——公共分支用 merge私有分支随便 rebase。✅ 自己的 feature 分支变基同步主干、整理提交随意✅ 提 PR 前把自己的分支 rebase 到最新审阅者看到的是干净的 diff❌ 别人的分支、已发布的 release 分支碰都不要碰六、总结回到开头的案例整个流程浓缩成三句话同步git fetch origin一步拿到云端所有分支最新状态不用切分支变基git rebase origin/develop/machine_S115把自己的提交重放到最新主干上强推历史重写后用git push --force-with-lease安全更新云端最后编译验证选型口诀“公共分支 merge私有分支 rebase强推只认 --force-with-leaserebase 完必须编译。”本文案例来自笔者在 MCU 固件项目中的真实操作记录终端输出均为原文。如果对你有帮助欢迎点赞收藏