变基仅适用于未推送的本地分支；一旦推送，必须禁用变基，否则破坏协作历史、导致重复提交、丢失修改、ci失败及pr关联断裂。公共分支（main/develop等）严禁变基，必须用merge以保留可追溯的合并记录。
变基只适用于未推送的本地分支
一旦 git push 过，就别对这个分支做 git rebase ——这不是建议，是硬性边界。因为 rebase 会重写提交哈希，远程分支上原有的 commit id 全部失效，队友 git pull 后会看到重复提交、冲突历史、甚至丢失修改。
常见错误现象：
- 你
rebase后push --force，队友git pull报错 “non-fast-forward”，然后手动reset或rebase自己的本地分支，结果把刚写的代码搞丢了 - CI/CD 流水线基于旧 commit id 触发构建，变基后找不到对应提交，构建失败或误用缓存
判断依据很简单：执行 git branch -v，如果某分支后面跟着 [origin/xxx: behind 2] 或类似远程追踪信息，说明它已共享——这时只能 merge，不能 rebase。
公共分支（main / develop）禁止变基
main、develop、release/* 这类被多人跟踪的分支，必须用 git merge 整合。它们不是“你的”分支，而是协作契约的锚点。
为什么？
-
merge生成的合并提交（merge commit）明确记录了“谁、何时、把哪条分支合入”，可追溯、可审计、可git bisect定位问题 -
rebase会抹掉分支来源信息，比如一个 hotfix 是从main切出再合回，变基后看起来就像直接在main上写的，失去上下文 - GitHub/GitLab 的 PR/MR 状态、评论、CI 记录都绑定原始 commit，变基后这些关联全部断裂
feature 分支变基前必须确认无共享
你本地的 feature/login 分支，在 git push origin feature/login 之前，可以放心 rebase；但只要执行过一次推送，后续所有变基都必须同步通知协作者，并要求他们放弃本地该分支、重新 git checkout -b feature/login origin/feature/login。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
实操建议：
- 日常开发中，用
git config --global pull.rebase true，让git pull默认等价于git fetch + git rebase，只影响你本地拉取行为，不改动远程 - 准备提 PR 前，先
git fetch origin main，再git rebase origin/main（确保目标分支是远程最新，而非本地 stale 的main） - 如果变基过程中出现冲突，每解决一个
git add后必须git rebase --continue，中途退出要用git rebase --abort，不要留半截状态
merge 和 rebase 混用时的关键顺序
团队采用“rebase before merge”流程时，必须严格遵守：先 rebase，再 merge --ff-only。否则可能意外触发三方合并，破坏线性历史。
典型错误操作：
- 你在
feature上rebase main完毕，但没切回main就直接git merge feature→ 此时 Git 发现feature已是main的后代，走快进（fast-forward），没问题 - 但如果你在
main上又提交了一次（比如修复 CI 脚本），再git merge feature→ Git 找不到共同祖先，强制创建合并提交，白费前面的rebase
所以推荐命令链：git checkout main && git pull && git checkout feature && git rebase main && git checkout main && git merge --ff-only feature。其中 --ff-only 是安全阀，非快进就报错，逼你检查是否有人偷偷往 main 提交。
真正容易被忽略的，不是语法或步骤，而是“分支所有权”意识：谁 last push，谁就承担历史一致性责任。变基不是整理工具，是重写契约——只有没签过字的草稿，才允许涂改。
