文章目录看懂 Git 团队协作全流程分支、提交、PR、rebase 到底在干嘛一、一句话总览二、用改合同理解每个核心概念三、完整流程图8 步四、术语速查表对照流程位置五、最常问的几个问题1. 为什么不能直接提交到 main/develop2. rebase 和 merge 到底啥区别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 同步最新、改标题描述 │ └─ 再 pushPR 自动更新 │ ⑧ 导师 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合并先有这张地图再去记命令就顺了。命令忘了可以查但流程搞懂了才不会迷路。
文章目录看懂 Git 团队协作全流程分支、提交、PR、rebase 到底在干嘛一、一句话总览二、用改合同理解每个核心概念三、完整流程图8 步四、术语速查表对照流程位置五、最常问的几个问题1. 为什么不能直接提交到 main/develop2. rebase 和 merge 到底啥区别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 同步最新、改标题描述 │ └─ 再 pushPR 自动更新 │ ⑧ 导师 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合并先有这张地图再去记命令就顺了。命令忘了可以查但流程搞懂了才不会迷路。
