文章目录
- [看懂 Git 团队协作全流程：分支、提交、PR、rebase 到底在干嘛](#看懂 Git 团队协作全流程：分支、提交、PR、rebase 到底在干嘛)
-
- 一、一句话总览
- 二、用"改合同"理解每个核心概念
- [三、完整流程图（8 步）](#三、完整流程图（8 步）)
- 四、术语速查表（对照流程位置）
- 五、最常问的几个问题
-
- [1. 为什么不能直接提交到 main/develop？](#1. 为什么不能直接提交到 main/develop？)
- [2. rebase 和 merge 到底啥区别？](#2. rebase 和 merge 到底啥区别？)
- [3. 为什么有时候要 force push（强推）？](#3. 为什么有时候要 force push（强推）？)
- 六、总结
看懂 Git 团队协作全流程：分支、提交、PR、rebase 到底在干嘛
第一次用 Git 协作时，最懵的不是记不住命令，而是搞不懂这一整套流程为什么要这样走。这篇文章不讲命令细节，只讲"地图"------用大白话把整个流程和核心概念讲清楚，先有全局，再学细节就顺了。
一、一句话总览
团队有一份共享的正式代码 （通常叫 main 或 develop 分支）。你做任何新东西，永远是三步：
从正式代码复制一份草稿 → 在草稿上改 → 申请把草稿合并回正式代码。
这三步对应的 Git 操作就是：建分支 → commit → 开 PR。
二、用"改合同"理解每个核心概念
想象团队共同维护一份正式合同：
| 概念 | 大白话 | 合同类比 |
|---|---|---|
| 仓库 Repository | 项目的代码 + 历史记录 | 合同存放处 |
| 分支 Branch | 一条独立的开发线 | 正式合同 vs 你的草稿副本 |
| commit 提交 | 一次"存档" | 在草稿上贴张便签，记录改了什么 |
| push 推送 | 把本地改动传到云端 | 把草稿交给负责人 |
| PR (Pull Request) | 申请把分支合并回主干 | 申请"把我的草稿内容写进正式合同" |
| review 评审 | 别人审查你的改动 | 负责人审草稿 |
| merge 合并 | 把分支合进主干 | 把草稿内容正式写进合同 |
| rebase 变基 | 把你的提交"搬"到最新主干上 | 先拿最新版合同，再把自己的改动加上 |
核心就三件事：
- 分支 = 你的草稿，改它不影响别人。
- PR = 申请合并，让负责人先审查，别直接改正式代码。
- rebase = 同步最新，保证你的草稿基于最新的正式代码。
三、完整流程图（8 步）
develop（团队的正式代码，大家共享）
│
① clone：把仓库下载到你电脑
│
② 建分支：从 develop 切出你自己的草稿 feat/你的功能
│
③ 改代码：写功能、修 bug
│
④ commit：存档，记录你的改动
│
⑤ push：把草稿推到云端，别人才能看到
│
⑥ 开 PR：申请"把我的草稿合并回 develop"
│
⑦ 导师 review：提意见
│ ├─ 你按意见改（rebase 同步最新、改标题描述）
│ └─ 再 push，PR 自动更新
│
⑧ 导师 approve → 合并进 develop → 完成 ✅四、术语速查表（对照流程位置）
| 词 | 大白话 | 在流程哪一步 |
|---|---|---|
| clone | 下载仓库到本地 | ① |
| branch 分支 | 你的草稿副本 | ② |
| commit | 存档 | ④ |
| push | 把草稿传上云端 | ⑤ |
| PR | 申请合并 | ⑥ |
| review | 别人审查 | ⑦ |
| rebase | 把草稿"搬"到最新正式代码上 | ⑦（改的时候） |
| force push | 草稿搬家后，强制用新版覆盖云端旧版 | ⑦ |
| merge 合并 | 把草稿写进正式代码 | ⑧ |
五、最常问的几个问题
1. 为什么不能直接提交到 main/develop？
因为那是大家共用的正式代码。你直接改，改到一半提交了，别人拉下来就是坏的、半成品，还容易跟别人的改动打架。
放到分支上，坏也只坏你自己的草稿；通过 PR 让别人审查，确认没问题才合并进主干。分支是保护主干不被改坏的机制。
2. rebase 和 merge 到底啥区别？
- merge（合并） ：把两个分支"合在一起"，产生一个
Merge branch ...的合并提交，历史是分叉的。 - rebase（变基） ：把你的提交"搬"到另一个分支末尾，历史是一条直线，干净。
很多团队约定功能分支用 rebase 保持历史干净（git rebase develop），而不是 merge。
3. 为什么有时候要 force push（强推）？
- 普通 push = 追加新提交，不能改已有历史。
- force push = 覆盖，用你本地的历史覆盖远程。
rebase 会"改写历史"（你的提交位置变了），导致本地和远程对不上，普通 push 会被拒绝，这时就要 force push 覆盖。
注意 ：force push 只该用在你自己的分支上；如果别人也在同一个分支上工作，强推会抹掉他们的提交。
六、总结
一句话记住整个协作流程：
建分支（草稿）→ commit（存档）→ push（交上去）→ PR（申请合并）→ review（审查）→ rebase 改（同步最新）→ merge（合并）
先有这张"地图"，再去记命令，就顺了。命令忘了可以查，但流程搞懂了才不会迷路。