git rebase会改写提交历史，生成新sha-1，仅适用于未推送的本地分支或单人维护分支；协作中已推送的分支禁止rebase，否则导致他人pull时出现重复提交、冲突或丢失改动。
rebase 会改写提交历史，不是所有情况都该用
Git rebase 的核心作用是把一串提交“挪”到另一个基底上重放，结果是线性历史。但它会生成全新提交对象（SHA-1 改变），所以只要分支已推送到远程、别人可能基于它工作，就别轻易 rebase —— 否则对方 pull 会遇到冲突、重复提交、甚至丢失改动。
常见错误现象：git pull 后发现本地多出一模一样的提交（旧 SHA + 新 SHA 各一份）；协作中队友抱怨“你 rebase 了？我这边全乱了”。
- 适合用：
git rebase -i HEAD~3整理自己还没推的本地提交（比如合并 fixup、删除调试提交） - 慎用但有时必须用：向主干（如
main）同步最新变更时，用git rebase main替代git merge，前提是这个分支只有你一个人在用 - 绝对避免：
git push --force覆盖他人已基于的远程分支（除非团队明确约定并通知所有人）
交互式变基 rebase -i 怎么安全地编辑提交
git rebase -i 是最常被误操作的环节：一不小心删错行、选错动作、保存失败，就会中断或出错。它的本质不是“编辑提交”，而是“告诉 Git 对每个提交执行什么操作”，每行开头的命令才是关键。
使用场景：压缩多个提交、修改某次提交信息、拆分一个大提交、跳过某个有问题的提交。
- 常用操作词（必须写在每行最前面）：
pick（保留）、reword（改提交信息）、edit（停在这步让你改内容）、squash（合并到前一个）、drop（丢弃） - 参数差异：
HEAD~3表示从当前往前数 3 个提交（不含当前），不是“最近 3 次”；想包含当前提交，得用HEAD~2 - 容易踩的坑：保存退出后 Git 报
error: cannot rebase: You have unstaged changes→ 先git stash或提交干净再操作
rebase 过程中遇到冲突怎么解
冲突不是失败，是 Git 在告诉你：“这个提交里改的代码，在新基底上没法自动套用，得你来确认怎么合并”。和 merge 冲突一样要手动改文件，但后续操作不同：不是 git commit，而是 git add + git rebase --continue。
性能影响：如果冲突发生在很早的提交上，后面所有提交都会依次重放，可能反复冲突多次——这时不如暂停 rebase，先 git checkout 回原始分支，用 git cherry-pick 逐个搬提交更可控。
- 典型错误：解决完冲突直接
git commit→ 会导致多出一个 merge 提交，破坏 rebase 的线性目标 - 正确流程：
git add <file></file>标记冲突已解 →git rebase --continue继续后续提交重放 - 想放弃整个 rebase：
git rebase --abort（会回到 rebase 前状态，安全）
为什么 git pull --rebase 比默认 pull 更干净
默认 git pull = git fetch + git merge，每次拉取都会产生一个 merge 提交，时间一长历史图谱变成蜘蛛网。而 git pull --rebase = git fetch + git rebase，把你的本地提交“顺”到远程最新提交之后，保持主线平直。
兼容性注意：它只影响你本地未推送的提交，不改远程历史，所以比手动 rebase 安全得多，适合日常开发同步。
- 推荐配置成默认行为：
git config --global pull.rebase true，之后所有git pull都等价于git pull --rebase - 但要注意：如果本地有 merge 提交（比如你刚
git merge feature过），pull --rebase会尝试把整个 merge 提交也 rebase，大概率失败 → 此时老实用git pull - 别指望它解决所有问题：如果远程已有别人基于你旧提交做的改动，
pull --rebase仍会触发冲突，得手动处理
真正难的不是命令怎么敲，而是判断“此刻该不该 rebase”——历史要不要线性、协作边界在哪、有没有人正基于你的分支工作。这些没法靠文档教，只能靠一次踩坑记住一次。
