必须从本地未推送的提交开始rebase -i，因为rebase会重写提交哈希，若已推送则破坏协作历史，导致他人分支失效、重复提交或冲突升级；仅限本地未共享分支操作。
git rebase -i HEAD~N 为什么必须从本地未推送的提交开始
rebase -i 只能安全操作尚未 git push 到远程的提交。一旦提交已公开，重写历史会导致协作混乱——别人基于旧哈希值的分支会失效，git pull 后出现重复提交或冲突升级。
- 检查是否已推送：
git log origin/main..HEAD—— 若有输出，说明这些提交还没推上去，可放心操作 - 如果已执行过
git push，又想瘦身，必须配合git push --force-with-lease（而非--force），避免覆盖他人新提交 - 团队约定：所有 feature 分支默认不直接推到
origin/main，只推到origin/feature/xxx，为 rebase 留出窗口
交互式变基中 squash 和 fixup 的实际区别
两者都用于合并提交，但语义和结果不同：squash 保留当前提交的 commit message 并与前一个合并；fixup 完全丢弃当前 message，只保留前一个的标题和正文。
- 用
squash（或s）适合你想把多个小步聚合成一个逻辑完整的提交，比如把"add test helper"+"fix test helper typo"+"update helper doc"合成"refactor: add robust test helper" - 用
fixup（或f）适合纯修复类提交，如"fix lint error"、"typo in comment"，你不想它们在历史里留下痕迹 - 编辑器保存退出后，Git 会自动打开新窗口让你编辑合并后的 commit message —— 这一步不能跳过，否则会沿用第一个 pick 提交的内容
rebase --onto 解决“跨分支剪枝”问题
当你要把某段提交从一个中间分支“挪”到另一个基础分支上（比如把 feature-v2 中一部分改动移到 main 上，跳过 dev），就得用 rebase --onto。
- 典型命令：
git rebase --onto main dev feature-v2，含义是：把feature-v2中「在dev之后、feature-v2当前 HEAD 之前」的那些提交，重新应用到main顶端 - 关键点：
dev是“旧基线”，main是“新基线”，feature-v2是要被移动的分支 —— 顺序不能错 - 容易误判的是
dev的位置：它必须是feature-v2的祖先，否则 Git 会报错fatal: upstream branch does not contain ...
rebase 后如何验证变更完整性
rebase 会生成新 commit hash，但内容是否一致？不能只看日志，得比对实际 diff。
- 变基前先记下原始范围：
git range-diff main...feature（Git 2.23+ 支持），它会逐行对比两个分支的提交差异 - 如果没有
range-diff，可用临时标签锚定：git tag before-rebase feature，rebase 完再运行git diff before-rebase..feature - 特别注意二进制文件或 submodule：
git diff默认不显示它们的变化，加--submodule=diff或--binary参数才可靠
真正麻烦的不是命令敲错，而是忘了某个提交里悄悄改了 CI 配置或环境变量 —— 那些改动不会出现在代码 diff 里，但会影响构建结果。每次 rebase 后，至少跑一次本地 make test 或对应验证流程。
