交互式变基git rebase -i是本地提交历史的精确编辑器，安全前提是未推送到共享分支；选起始commit应先用git log --oneline -n 5确认，推荐用目标最早提交的前一个哈希加^，或head~n（n≤5）避免数错。
交互式变基 git rebase -i 不是用来“改历史”的魔法，而是你本地提交历史的精确编辑器——只要没推送到共享分支，它就是安全、可控、可逆的整理工具。
怎么选对起始 commit？HEAD~N 容易数错
很多人输 git rebase -i HEAD~3 想合并最近 3 次提交，结果发现少了一条。因为 HEAD~3 是指「当前提交往前跳 3 步」的那个提交，实际操作范围是它之后的所有提交（不含它自己），共 3 个。想包含当前提交，得用 HEAD~2。
- 最稳妥的方式是先看日志：
git log --oneline -n 5，抄下你想保留的最旧那个提交的前一个哈希值，比如abc1234，再执行git rebase -i abc1234 - 如果只是临时整理，
HEAD~N没问题，但建议 N ≤ 5；超过这个数，编辑器里容易看花眼、删错行 -
git rebase -i main也合法——它会列出从main分支分叉点之后的所有提交，适合功能分支收尾时统一整理
编辑界面里改哪几行？命令写错就中断
打开编辑器后，每行开头的动词才是 Git 真正执行的动作。删掉某行 = drop，但不推荐直接删，容易误操作；明确写 drop 更清晰。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
-
squash和fixup都要作用于「它上面那行 pick 的提交」：第二行写squash，就是合并到第一行；第三行写fixup，就是合并到第二行（不是第一行） -
reword只改消息，不影响代码；edit会停在该提交，让你git add+git commit --amend后再git rebase --continue - 所有命令必须顶格写，前面不能有空格；保存前检查有没有拼错单词，比如把
fixup写成fixup（少个 f）或fix-up（带连字符）都会报错退出
为什么一保存就报 error: cannot rebase？
常见中断原因不是命令写错，而是工作区不干净。Git 要求变基全程无未提交变更，否则拒绝启动重放流程。
- 运行
git status，确认输出是 “nothing to commit, working tree clean” - 如果有未暂存修改，要么
git stash暂存，变基完再git stash pop；要么先git add+git commit提交掉 - 如果中途遇到冲突（比如
edit后改了文件又git commit），解决完记得git add标记已解决，再git rebase --continue；别直接git commit，否则会多出一个提交
push 时提示 non-fast-forward 怎么办？
本地历史被重写后，远程分支和你本地不再同源，git push 默认被拒绝。这时必须用 --force-with-lease，而不是 --force。
-
git push --force-with-lease origin feature-branch：它会检查远程分支自你上次 fetch 后是否被别人更新过，有更新就中止，避免覆盖他人推送 - 如果团队约定允许 force push，也要提前通知协作者；一旦推送，别人本地的旧分支引用就失效，需
git fetch && git reset --hard origin/feature-branch强制同步 - 永远不要对
main或develop这类共享分支做rebase -i后 force push，这是协作红线
真正容易被忽略的，是 rebase -i 后所有提交的哈希值全部重算——这意味着 CI 构建记录、PR 关联、甚至某些基于 commit ID 的自动化脚本都会断开。别只盯着“看起来更整洁”，先确认下游系统是否依赖原始 commit ID。
