git rebase origin/main 不能直接使用，因其会重复重放已合并的提交，导致重复 commit 和冲突；应先用 git log origin/main..head 确认范围，再用 git rebase -i origin/main 交互式操作，慎用 squash/fixup，并以 --force-with-lease 推送；仅私有特性分支可变基，公开分支禁止变基。
git rebase origin/main 为什么不能直接用
因为 git rebase origin/main 默认会把当前分支所有「未在 origin/main 中的提交」都搬过去，但如果你本地已经 merge 过别人推送的提交（比如通过 git pull --no-rebase），这些提交会被重复重放，导致重复 commit、冲突反复出现，甚至引入重复变更。
正确做法是先确认要变基的范围：
- 用
git log origin/main..HEAD查看「仅在当前分支、不在 origin/main 上」的提交列表 - 如果看到大量 merge commit 或你不确定哪些该保留，改用交互式变基：
git rebase -i origin/main - 在编辑器里删掉不需要的行（比如误提交、调试用的临时 commit），保存退出后按提示解决冲突
交互式变基中 squash 和 fixup 的区别
squash 和 fixup 都用于合并前序 commit，但处理方式不同：前者会打开编辑器让你重写合并后的 commit message，后者直接丢弃被合并 commit 的 message，只保留前一个的。
典型误用场景：把一个功能拆成 5 次小提交，最后想压成 1 个干净 commit —— 正确顺序是把第 2–5 行都标为 fixup，第 1 行保持 pick；这样既省去编辑 message 的步骤，又避免漏掉某条 commit。
注意：fixup 不会校验 commit 内容是否真的相关，只是机械拼接 diff，所以如果中间某次提交删了关键代码，fixup 后可能直接破坏功能。
push --force-with-lease 而不是 --force
强制推送变基后的分支时，--force 会无条件覆盖远程，哪怕别人刚推了新提交也会被悄无声息抹掉；而 --force-with-lease 会在推送前检查远程引用是否和你本地记录的一致，不一致就中止，防止覆盖他人工作。
辅助阅读和快速理解 GitHub/Git 项目结构与核心价值的结构化方法论。 当用户请求"分析这个 GitHub 项目"、"帮我读一下这个 repo"、"了解这个项目是做什么的"、 "怎么用这个项目"、"怎么跑这个项目"、"这个项目用了哪些技术"，或任何涉及 GitHub/Git 仓库阅读、理解、技术评估、快速上...
更安全的做法是给它加个别名：
git config --global alias.fpush "push --force-with-lease"
之后只需执行 git fpush origin feature/login。如果遇到 “rejected” 提示，说明远程已有新提交，这时应该先 git fetch，再决定是 rebase origin/feature/login（继续变基）还是放弃强制推送。
团队协作中哪些分支不该变基
已公开共享的长期分支（如 main、develop、release/*）绝对不要变基。变基本质是重写历史，一旦其他人基于旧 commit 继续开发，他们的本地分支就会和远程“失联”，后续 merge 会出现大量虚假冲突。
适合变基的只有你自己正在开发、尚未合入主干的特性分支（如 feature/user-profile），且必须确保没有同事基于它做二次开发。如果团队用 PR/MR 流程，建议在 PR 页面点击 “Update branch”（自动 rebase onto main）而非本地手动操作，避免遗漏更新远程跟踪分支。
最常被忽略的一点：变基后 git status 显示 “Your branch is up to date”，但其实本地分支指针已指向全新 commit 链，原来的 commit ID 全部失效——这意味着所有基于旧 ID 的评论、CI 记录、issue 关联都会断开。
