图解 Git 工作流：理解 Rebase、Merge 与 Pull Request 的区别
在多人协作开发中，选择合适的 Git 分支管理策略至关重要。Merge、Rebase 和 Pull Request 是最常见的三种方式，它们本质不同，使用场景也不同。
本文将通过流程图（使用 Mermaid 格式）来详细解释三者的工作机制、优劣对比和最佳实践。
一、Merge 工作流图：保留分支结构
main 分支提交 A 提交 B feature 分支提交 C 提交 D main 分支继续提交 E 执行 merge 操作 生成 merge commit
✅ 特点
- 保留所有分支和提交历史
- 清晰展现开发流程
- 会创建一个合并提交（merge commit）
二、Rebase 工作流图：线性提交历史
main 分支 提交 B feature 分支提交 C 提交 D main 分支继续提交 E 执行 rebase 操作 feature 分支提交 C' feature 分支提交 D'
✅ 特点
- 提交历史线性、整洁
- 修改了提交哈希
- 不适合公共分支使用
三、Pull Request 流程图：代码审查与协作
graph LR
A[main 分支：提交 A] --> B[提交 B]
B --> C1[feature 分支：提交 C]
C1 --> C2[提交 D]
B --> D[main 分支继续提交 E]
C2 --> E1{发起 Pull Request}
D --> E1
E1 --> F[代码审查/CI 检查]
F --> G{选择合并方式}
G --> H[merge 或 rebase 方式合并进 main]
✅ 特点
- 跨团队协作首选
- 可配置 CI、审批流程
- 最终由项目管理员决定合并方式
四、三者对比表
| 功能/特性 | Merge | Rebase | Pull Request |
|---|---|---|---|
| 历史结构 | 分叉结构，保留所有分支 | 线性历史，清晰整洁 | 可选择 merge 或 rebase |
| 是否生成新提交 | ✅ 合并提交 | ❌ 不生成额外提交 | ✅ 可生成（取决于合并策略） |
| 是否更改提交哈希 | ❌ 保留原提交 | ✅ 会重写提交历史 | ❌ 默认为保留 |
| 推荐使用场景 | 多人协作、需保留开发分支记录 | 个人开发、整理历史 | 团队协作、审核流程 |
五、最佳实践建议
- ✅ 本地个人开发可使用
rebase，提交更整洁 - ✅ 推送远程协作开发建议使用
merge - ✅ 所有特性分支合并到主分支前应通过 Pull Request
- ⚠️ 不要对公共分支执行
rebase，会导致历史冲突
六、总结
不同的 Git 工作流方式适用于不同的团队与开发阶段：
- Merge 更加保守、安全
- Rebase 更整洁、高效
- Pull Request 更适合团队协作与代码审查
灵活选择，才能发挥 Git 的最大威力。