git rebase 不能直接作用于远程分支（如 origin/main），因其仅为本地快照、不可写；真正可变基的是本地分支，目标基底可为本地分支或远程跟踪分支，需先 fetch 更新再操作。
远程分支上直接变基是危险操作，除非你完全掌控该分支且团队已同步知晓——否则会破坏他人本地历史，引发协作混乱。
git rebase 不能直接作用于远程分支
你无法对 origin/main 这类远程跟踪分支执行 git rebase。Git 会报错：refusing to rebase onto a dangling branch 或提示“not a valid ref”。因为远程分支只是本地对远端状态的快照，不是可写分支。
- 真正能变基的是你的本地分支（比如
feature/login），目标基底可以是另一个本地分支（main）或其对应的远程跟踪分支（origin/main） - 常见误操作：运行
git rebase origin/feature-x—— 如果origin/feature-x已被删除或未同步，本地没有对应提交，就会失败 - 安全做法：先
git fetch origin更新所有远程跟踪分支，再确认基底存在
想让远程分支“看起来”被变基了，得靠强制推送
变基只改本地分支指针和提交哈希；要让远端也“更新”，必须用 git push --force-with-lease 替换远端引用。这不是变基本身的功能，而是后续同步动作。
-
--force-with-lease比--force安全：它会检查远端分支是否被别人更新过，若已被他人推送，操作会被拒绝，避免覆盖他人工作 - 必须明确指定推送目标：
git push --force-with-lease origin feature/login:feature/login，不能省略冒号后的远程分支名 - 如果远程分支受保护（如 GitHub/GitLab 的 branch protection rules），即使加了
--force-with-lease也会被拒绝，需临时关闭保护或走 PR 流程
多人协作中哪些场景真需要远程分支变基
几乎没有。所谓“远程分支变基”，95% 的实际需求其实是以下三种之一：
- 同步本地功能分支到最新主干：
git checkout feature/login && git rebase origin/main，然后push --force-with-lease - 清理自己尚未合入的私有分支历史：
git rebase -i origin/main合并/重排/修正提交，再推送到自己的远程分支 - 修复刚推上去、无人基于其开发的提交（比如误提交敏感信息）：
git rebase -i HEAD~3+drop+ 强推
注意：只要该分支 URL 被他人 git clone 或 git remote add 过，就不算“无人使用”——哪怕没人 checkout，也可能被 CI 系统拉取。
rebase --onto 移植提交时容易漏掉的基点参数
用 git rebase --onto 把一段提交从 A 分支移到 C 分支，常因搞错三个参数顺序出错。标准格式是：
git rebase --onto <new-base> <old-base> <branch-to-rebase>
例如：想把 feature/refactor 中从 main~5 之后的所有提交，移到 origin/staging 上：
- 错误写法：
git rebase --onto origin/staging main~5 feature/refactor—— 表面看对，但main~5是旧基底起点，Git 会从该点**之后**的提交开始搬，不包括它自己 - 正确写法：
git rebase --onto origin/staging main~5 feature/refactor✅（前提是main~5确实是那段提交的共同祖先） - 更稳妥写法：用
git merge-base算准分叉点：git rebase --onto origin/staging $(git merge-base main feature/refactor) feature/refactor
漏掉 <old-base> 或填错，会导致部分提交被跳过，或重复应用——这种问题在交互式变基里看不到提示，只能靠 git log --oneline --graph 对比前后结构。
