变基后必须强制推送才能更新远程分支，因rebase重写了提交哈希，导致本地与远程历史不兼容；直接push会因非快进被拒，需用git push --force-with-lease，若提示stale info则说明他人已推送新提交，应先fetch再决定是否二次rebase或协调同步。
变基后必须强制推送，否则远程分支不会更新，本地干净的历史等于白做。
git rebase origin/main 后为什么 push 不上去？
因为 rebase 会重写提交哈希，本地分支指针已指向一串新提交，而远程分支仍停留在旧提交上。Git 默认拒绝这种“非快进”推送，防止覆盖他人工作。
- 直接
git push会报错：! [rejected] feature-x -> feature-x (non-fast-forward) - 必须用
git push --force-with-lease origin feature-x覆盖远程历史 -
--force-with-lease比--force安全：它会检查远程分支是否被他人更新过，若已被改写则中止推送，避免误覆盖 - 如果推送失败并提示
stale info，说明别人已往该分支 push 过新提交——此时不能硬推，需先git fetch origin，再决定是 rebase 新内容还是协调同事
什么时候该 rebase 到 origin/main，而不是 merge？
目标是让功能分支的提交历史线性、无合并记录，适合用于 PR/MR 前清理。典型场景是：你长期在 feature-x 上开发，期间 main 被多人更新多次。
- 用
git rebase origin/main把你的所有提交“挪到”最新main之后，历史变成main→ 你的提交（顺序不变） - 不要用
git merge origin/main，否则会产生Merge branch 'main' into feature-x提交，污染历史 - 如果
main在你开发期间只有一两个小更新，且你没改冲突文件，rebase几乎无感；若改动密集或涉及公共配置，大概率要手动解决冲突 - 注意：rebase 后的提交 ID 全变了，所有基于旧提交打的 tag、CI 构建记录都失效——这点常被忽略
git push --force-with-lease 失败怎么办？
失败通常意味着远程分支已被他人更新，而你的本地还停留在老状态。这不是操作错误，而是协作中的正常竞争。
- 先执行
git fetch origin拉取最新远程状态 - 运行
git status或git log origin/feature-x..feature-x确认你本地比远程多了哪些提交 - 如果确认没人正在该分支上工作，可加
--force强推（不推荐）；更稳妥的是git rebase origin/feature-x，把你的变更叠在他人最新提交之上 - 若他人提交与你无关（比如只是 CI 配置修复），也可协商请对方
git reset --hard origin/feature-x回退，再让你推 - 切记：任何强制推送前，务必在团队群同步一句“即将 force-push feature-x”，留出 5 分钟缓冲期
真正难的不是命令怎么敲，而是判断「谁在动这个分支」「哪些提交能删」「tag 和 CI 是否可接受哈希变更」——这些没法靠 git rebase -i 自动解决。
