让团队不再互相踩脚的
Git 分支协作术

分支规范 · feature 日常开发流 · merge 与 rebase 的本质区别 · 冲突解决实战——配一台「命令 ↔ 图形」同屏对照的 Git Graph 模拟器，把每一条命令在提交图上的效果亲眼看一遍。

📚 8 个章节 🎬 Git Graph 模拟器 × 4 场景 📝 7 组测验 · 28 题 ⏱ 40–60 分钟 💾 进度自动保存

一句总纲

分支 = 随时可以开、随时可以扔的平行宇宙；merge 与 rebase = 两种把平行宇宙的成果带回主世界的方式；所有协作规范，都是为了让多人同时开发互不踩脚。

💥 先看一场事故：所有人都在同一条线上提交

一个三人小团队，没有任何分支规范，所有人直接往 main 上提交。点击「播放事故」，看看一个再普通不过的周三是怎么失控的：

DEMO 1一条 main 走天下 · 灾难剧场点「播放事故」逐条看

09:12 · 甲把写到一半的「登录重构」直接 push 到 main——能编译，但一半接口还是 TODO。「先存个进度，不影响别人吧？」

09:40 · 乙git pull 之后本地登录彻底跑不起来。排查 40 分钟，才发现拉下来的是甲的半成品。乙的上午报废。

10:05 · 丙修一个支付 bug，改完顺手也 push 到 main——赶时间没跑测试，悄悄引入了一个新 bug。

11:00 · 老板「客户在等，现在马上发版！」

11:01 · 全员main 上混着半成品登录 + 没测过的支付修复，谁也不敢发。只能人肉挑提交、手工回滚，加班到深夜 😵

复盘事故的根源不是谁的代码烂，而是所有人共享同一条可变的时间线：任何人的中间状态都会立刻污染所有人。解法：给每人一个「平行宇宙」，做完、验收合格，再并回主世界——这就是分支。

🌌 分支 = 平行宇宙，但便宜得多

科幻片里的平行宇宙设定是：从某个时间点分裂出一条独立时间线，里面随便折腾，不影响主世界。Git 的分支就是这个设定的工程实现——你从 dev 的某个提交「分裂」出 feature 分支，在里面写半成品、做实验、反悔重来，主世界毫无感知；直到你主动把成果合并回去。

而且它比科幻片便宜：Git 的分支不是代码的副本，只是一个 41 字节的小文件，里面记着「这个分支目前指向哪个提交」。开 100 个分支，仓库也不会大 1KB。

🧬

提交（commit）是不可变的快照

每个提交 = 整个项目的一张快照 + 指向父提交的引用 + 一个由内容算出的哈希（如 a1f9c2）。内容变一个字节，哈希就完全不同——这是后面理解 rebase 的关键。

🏷

分支只是一张会动的便签

「main」「dev」本质是贴在某个提交上的便签（指针）。在分支上提交，便签自动前移；删除分支只是撕掉便签，提交本身还在。

📍

HEAD 是「你现在站在哪」

HEAD 指向你当前所在的分支。git switch 就是把 HEAD 挪到另一张便签上，工作目录随之切换到那条时间线的模样。

💡 使用说明

所有带 DEMO 标签的组件都可以点、可以玩；第 3 章的 Git Graph 模拟器是本页灵魂，四个场景把 merge / rebase / 冲突全部演一遍。每章末尾有随堂小测，全部答对该章即「点亮」；进度存在浏览器本地（localStorage），关掉重开不丢。

第 1 章

🏷 分支规范：给每条时间线一个职责

main / dev / feature / release / hotfix · 保护分支 · 三大协作模型 · 提交信息规范

一句话版本

分支规范的本质是职责分离：main 永远可发布、dev 汇集下个版本、feature 隔离每个功能、hotfix 抢救线上——名字则让人一眼看懂「这条时间线是干嘛的」。

🧭 五种分支，各管一段

🏛

main（主分支）

永远等于线上正在跑的代码，随时可发布。只接受来自 release / hotfix 的合并，每次合并打版本 tag。任何人不得直接 push。

🧪

dev / develop（开发分支）

下个版本的「集结地」：所有 feature 验收后先汇集到这里做集成测试。它可能偶尔是坏的——没关系，main 稳着呢。

🌿

feature/*（功能分支）

每个功能一条，从 dev 拉出、做完合回 dev、随即删除。生命周期越短越好（几小时到几天），越长越容易和别人冲突。

🚑

hotfix/*（热修复分支）

线上着火时，从 main 拉出（不能从 dev——那里混着没验收的新功能），修好后同时合回 main 和 dev，否则下次发版 bug 复活。

📦

release/*（发布分支）

从 dev 拉出的「冻结候选版」：只修 bug、不加功能，QA 验收通过后合入 main 打 tag，同时回灌 dev。

✍️ 命名规范：让分支名自我介绍

团队常见约定：类型/简短描述（kebab-case）

# ✅ 好名字：一眼看懂类型和内容
feature/cart              # 购物车功能
feature/order-export      # 订单导出
fix/login-crash           # 修登录崩溃（有的团队用 bugfix/）
hotfix/pay-timeout        # 线上支付超时热修
release/2.4.0             # 2.4.0 发布分支

# ❌ 坏名字：三天后没人（包括你）知道是干嘛的
dev2  test  temp  wang/backup  new-branch-final-v3

💚 要点

斜杠不是特殊语法，只是约定俗成的「命名空间」——但几乎所有图形工具（Git Graph、SourceTree）都会把 feature/ 前缀识别成文件夹分组展示，团队大了尤其受益。

🛡 保护分支：把规范变成「物理防御」

规范靠自觉是守不住的。托管平台（GitHub / GitLab / Gitee）提供保护分支（protected branch）规则：对 main 和 dev 开启后，任何人（包括管理员）都无法直接 push，代码只能通过 Pull Request / Merge Request 进入，并可强制要求：至少 N 人 Review 通过、CI 全绿、分支必须先同步最新目标分支。第 0 章的事故里，甲丙的两次「顺手 push」在这道门前都会被物理拦下。

⚖️ 三大主流协作模型：没有最好，只有合身

维度	Git Flow	GitHub Flow	Trunk-Based
长期分支	main + develop 双主线，外加 feature / release / hotfix	只有 main，一切改动走短命 feature 分支	只有 main（trunk），分支寿命 < 1–2 天甚至直接提交
发布方式	按版本周期发布（release 分支 + tag）	合并即可部署，随时发布	持续部署，配合特性开关隐藏未完成功能
优点	职责最清晰，多版本并行维护从容	简单直白，学习成本最低	集成最频繁，冲突最小，交付最快
代价	流程重、分支多，小团队易被拖慢	多版本维护乏力	对自动化测试与 CI 成熟度要求极高
适合谁	按版本发布的中大型团队 / 客户端软件	持续部署的 Web 小团队（3–10 人）	工程文化成熟的大厂 / 高频交付团队

本页教学采用最普遍的「简化 Git Flow」：main + dev + feature/hotfix——这是国内多数业务团队的实际形态，也正是你的团队描述的样子。

💬 提交信息也有规范：Conventional Commits

分支管住了「时间线」，提交信息管住「每个节点讲了什么」。Conventional Commits 约定 类型(范围): 描述 的格式，机器可解析（自动生成 changelog、语义化版本），人类可速读：

Conventional Commits 速览

feat(cart): 支持批量加入购物车        # 新功能
fix(login): 修复验证码过期不提示       # 修 bug
docs(readme): 补充本地启动步骤         # 只改文档
refactor(order): 拆分订单状态机        # 重构（不改行为）
test(pay): 补支付回调的边界用例        # 只加测试
chore(deps): 升级 axios 到 1.8        # 杂务（构建/依赖等）

# 破坏性变更：类型后加 "!"，正文里写 BREAKING CHANGE:
feat(api)!: 订单接口返回结构改为分页

✅ 本章小结

main 永远可发布；dev 是集结地；feature 短命隔离；hotfix 从 main 拉、双向合回。
分支名 = 类型/描述（feature/cart、fix/login-crash），图形工具会按前缀自动分组。
保护分支把规范变成物理防御：main/dev 只进 PR，不接受直接 push。
Git Flow 重而全、GitHub Flow 轻而快、Trunk-Based 快而险——按团队规模与发布方式选。
提交信息用 Conventional Commits：feat / fix / docs / refactor / test / chore。

📝第 1 章随堂小测全部答对即点亮本章

🏅第 1 章通关！分支的「户口制度」拿下，接下来看每天真正要跑的流程。