必须用 git rebase 同步主干更新的场景是：你在独占的本地 feature 分支开发时，main 已有新提交，需将 feature 变更逐个重放到最新 main 之后，避免 merge commit 并保持历史线性；但绝不可在已推送且他人正在基于其开发的分支上使用。
Git rebase 能让分支历史变线性，但不是所有场景都该用——它本质是重写提交哈希，一旦推送到共享分支，就可能让协作者的本地仓库“失联”。
什么时候必须用 git rebase 同步主干更新
你在 feature 分支开发时，main 已有新提交，想把 feature 的变更“叠”到最新 main 之上，而不是产生一个 merge commit：
- 执行
git checkout feature && git rebase main，会逐个重放feature上的提交到main最后一个提交之后 - 如果
feature是你个人独占的本地分支（没被其他人基于它开发），这是安全且推荐的做法 - 若
main中有大量重构（如文件重命名、函数拆分），rebase 比 merge 更容易暴露冲突点，因为每个提交单独应用，而非整体合并 - 注意：不能在已
push到远程且他人正在基于它工作的分支上执行此操作，否则他们git pull时会看到重复提交或丢失变更
交互式 rebase（git rebase -i）整理提交的典型误操作
你想压缩 5 个临时提交为 1 个语义清晰的提交，运行 git rebase -i HEAD~5 后，在编辑器里把后 4 行改成 squash，结果报错 error: cannot 'squash' without a previous commit：
- 必须确保第一行是
pick，后续才能squash到它上面；顺序颠倒或首行也写squash就会失败 - 如果某次
squash后编辑提交信息时保存了空内容，rebase 会中断并提示Aborting commit due to empty commit message，需重新git rebase --edit-todo修正 - 不要在
reword行里修改哈希值（哪怕只改一个字符），Git 会认为目标提交不存在，直接中止 - 完成 squash 后，Git 会打开默认编辑器让你写新提交信息——此时若直接退出不保存，也会中止流程
git rebase 冲突时为什么 git add 后还不能 --continue
解决完 example.txt 的冲突并 git add example.txt，执行 git rebase --continue 却提示 error: you must edit all merge conflicts and then mark them as resolved with git add：
- 常见原因是遗漏了其他冲突文件：
git status显示both modified的不止一个，但只add了其中一部分 - 另一个隐蔽情况：冲突文件里残留了 Git 的标记（
<<<<<< HEAD等），但未被完全删除，Git 仍视为未解决 -
git add必须作用于确切的冲突路径，比如文件在子目录，写成git add file.txt而非git add ./sub/file.txt（取决于当前工作目录），可能导致未真正标记为已解决 - 如果不确定是否全解决，用
git status --short查看所有标为UU的文件，逐个确认
rebase 后 git push 失败的直接原因和应对
本地 rebase 完毕，执行 git push origin feature 报错 ! [rejected] feature -> feature (non-fast-forward)：
- 这是正常现象：远程
feature分支的提交哈希链已被重写，Git 拒绝覆盖（防止误操作丢数据） - 唯一安全做法是
git push --force-with-lease origin feature，它比--force多一层检查——若远程分支在你上次fetch后被别人更新过，会拒绝强制推送，避免覆盖他人工作 - 切勿对
main、develop这类公共分支使用 force push，哪怕你确定没人动过；团队应约定这些分支只通过 PR/Merge 流程更新 - 如果已误用
--force覆盖了他人推送，立刻通知协作者运行git fetch && git reset --hard origin/feature拉回最新状态（前提是他们没做本地修改）
最易被忽略的一点：rebase 不是“撤销操作”，而是“生成新提交”。原提交对象仍存在于 .git/objects 中，直到被 Git 的垃圾回收（git gc）清理。这意味着，即使你 rebase --abort 或删掉分支，敏感信息若曾出现在某个提交里，仍可能被 git reflog 或他人通过 git fsck 找到——真要删密钥，得用 git filter-repo 或彻底清空仓库。
