上游 · 理解本功能前需先掌握的（1）：
下游 · 依赖/承接本功能的（3）：
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
你想加个新功能，又怕把好好的代码改坏？分支（branch）就是为此而生：它让你在一条'平行岔路'上放心实验，改坏了大不了不要这条岔路，主线一点不受影响。这是 Git 最优雅的设计之一。
历史背景 · 它为什么诞生诞生于 2005/2011
诞生多数VCS的分支需把整个源码目录复制到新目录，大项目耗时数秒甚至数分钟，导致团队回避频繁分支。Git的分支只是一个指向提交的可移动指针，创建分支仅需写41字节，操作瞬间完成，成为Git的"杀手锏"。
演进分支从"少数重量级操作"变为"日常开发单元"：2011年Scott Chacon发表GitHub Flow（master始终可部署→建描述性分支→推送→开PR评审→合并即部署），把SVN时代的昂贵分支简化为一日多次的分支-合并循环。
历史教训
降低操作成本会改变使用习惯：当分支成本趋近于零，频繁分支合并成为常态，工程纪律（评审、可部署性）随之建立。低成本抽象能重塑整个工作方式。
功能介绍
官方定义说，分支'让你能开发新功能、修复 bug 或安全地做实验'。分支是从某个既有分支'派生'出来的一条独立工作线：你在分支上的提交不会影响其他分支。仓库默认的主分支叫 main（早期也叫 master），通常是稳定的主版本所在。典型工作流是：从 main 上开一个功能分支（feature branch）→ 在分支上提交多次 → 完成后把分支合并回 main → 删除这个临时分支。切分支用 git checkout 或 git switch。分支是轻量级的，创建几乎零成本，所以大胆多用；'每件独立的事开一个分支'是专业团队的基本纪律。
核心术语
分支（branch）：从既有分支派生出的独立工作线main：仓库的默认主分支切换（checkout/switch）：在不同分支之间移动当前工作位置功能分支（feature branch）：专门开发某个功能的分支派生（derive）：新分支从某个提交点延伸出来
适用场景
- 当你想开发新功能、又不想影响正在运行的稳定代码时
- 当你想尝试一个实验方案、可能随时放弃时
- 当你和队友各做各的功能、需要互不干扰时
- 当你想修复紧急 bug、又不想带上未完成的新功能时
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 在仓库页面上方点击分支选择器（显示当前分支名），搜索或输入名字创建新分支
- 在 Pull Request 页面选择源分支和目标分支查看对比
- 在 'Branches' 标签页查看所有分支并管理删除
⌨️ 命令行 (进阶)
git branch feature-1 # 创建新分支 feature-1git checkout feature-1 # 切换到该分支（也可用 git switch）git checkout -b feature-2 # 一步完成创建并切换git branch # 查看所有分支，* 号标记当前所在分支
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 概念升级提交（Commit） | commit 是分支的内容，理解提交后才理解分支 |
| 流程承接合并（Merge） | 分支开发完成后合并回目标分支 |
| 流程承接拉取请求（Pull Request） | PR 比较 head branch 与 base branch，先懂分支 |
| 流程承接静态网站托管：GitHub Pages（页面） | 从指定分支发布静态站点（底层也是 Actions） |
官方文档
小结
SUMMARY
分支是一条可进可退的独立工作线，默认主分支是 main，新功能开新分支、完成再合并。'先开分支再动手'会让你从此告别改坏代码的恐惧。下一步：学会把分支的成果合并回主线。