3.6 Rebase、PR 与团队工作流

前置知识：远程仓库、fetch、pull 与 push

预计时间：15 分钟

阅读方式：第一次可抓住“不要重写别人依赖的提交”，参与协作时再细读策略

完成标志：知道 rebase 重写什么，并能选择合适的 PR 合并方式

本地远程实验解释了数据怎么移动，却还没有回答团队怎样审查和整合变化。接下来把 rebase、PR 和合并策略放在同一张提交图上讨论。

rebase 不是“让历史变漂亮”的按钮

rebase 把一组提交复制到新基线，因而产生新的提交 ID：

原来：A---B---C  main
          \
           D---E  topic

之后：A---B---C---D'---E'  topic

交互式 rebase 还能重排、合并、改消息或删除提交：

git rebase -i HEAD~3

这是交互命令示意：当前分支必须至少有三个可重写提交，且工作区已处理干净；它不会自动把 topic 移到 main，图中的换基需要指定新的基线。编辑器中的 todo 列表决定操作。先在临时分支练习，并记住冲突时用 git status、git rebase --continue 或 git rebase --abort。

判断标准是依赖关系：不要重写别人已经基于其工作的提交。已经推送的个人 PR 分支有时会在协商后 rebase；更新远程时使用 git push --force-with-lease，并理解它仍会改写历史。普通 --force 缺少远程引用检查。

PR 是托管平台流程

Pull Request（GitHub 等）或 Merge Request（GitLab 等）不是 Git 对象。它把分支差异、讨论、评审、自动检查和合并动作组织在一起。

常见流程：

1. 从目标基线更新后创建短期分支。
2. 做小而完整的提交，并在本地测试。
3. 推送主题分支，发起 PR，写明动机、验证和风险。
4. 按评审意见继续提交；同一 PR 自动更新。
5. 检查通过后按仓库规则合并。

同仓库成员通常直接推主题分支；外部贡献者常 fork 仓库，将原仓库命名为 upstream。两种方式都不是固定规则，取决于权限模型。

三种常见合并结果

• merge commit：保留分支拓扑和各提交。
• squash merge：把 PR 的净变化形成一个新提交。
• rebase merge：把主题提交复制到目标分支顶端。

选择要配合回滚、审计和发布习惯。提交多并不自动等于历史差；丢失能解释问题与验证过程的边界，反而会降低可维护性。

工作流名称不是规则本身

GitHub Flow、Git Flow、主干开发和发布分支各有适用条件。小团队持续部署常偏向短分支和主干；多版本维护或严格发布窗口可能需要长期发布分支。无论选择哪种，都要明确：

• 主分支是否必须可部署；
• 谁可以合并，哪些检查必须通过；
• 发布如何打标签和回滚；
• 紧急修复如何回流到其他维护分支。

需要查细节时

• Pro Git：Branches in a Nutshell 从对象与引用解释分支。
• Pro Git：Rebasing 展示 rebase 如何重放提交及公开历史的风险。
• git-merge 官方手册 给出冲突、--abort 和三方内容的检查方法。

→ 下一步：本地远程综合实验