本节目标：理解分支的价值，掌握 Pull Request 工作流，建立多人协作的日常节奏。
分支的本质就是"复制一份再改"，但比复制文件夹高明得多。它不会真的复制所有文件——Git 只记录差异，创建一个分支几乎不占额外空间。你可以随时在"原版"和"副本"之间切换，改好了可以精确地合并回去，而不是整个文件夹替换。
复制文件夹的问题在于：你在副本里改了 10 个文件，原版里也改了 3 个文件（修了个紧急 bug），现在你想把副本的修改合并回原版——你得手动对比 13 个文件，确保不遗漏、不覆盖。Git 的分支帮你自动完成这件事。
你的项目默认有一个主分支，通常叫 main（有些旧仓库叫 master）。它代表"当前稳定可用的版本"。当你要开发新功能时，从 main 创建一个新分支，比如 feature/recommend，在这个分支上随便折腾。改坏了？切回 main，一切如初。改好了？合并到 main，功能上线。
main 分支就像你的"正式版"，功能分支就像"草稿本"——你在草稿本上怎么涂改都不影响正式版，直到你确认满意了才把内容誊写过去。
main ─────────────────────────────────── (稳定版，不受影响)
│
└── feature/recommend ──→ 在这里开发推荐功能
改坏了？切回 main，一切如初
改好了？合并到 main，功能上线小明告诉 Claude Code "创建一个分支来开发推荐功能"，Claude Code 会创建 feature/recommend 分支并切换过去。从这一刻起，小明的所有修改都在这个分支上，main 分支纹丝不动。分支名通常用 feature/xxx 表示新功能，fix/xxx 表示修 bug，refactor/xxx 表示重构——这不是强制的，但能让你和协作者一眼看出这个分支在做什么。
为什么不直接把分支合并到 main？
想想你写过的文档——如果别人不看就直接改了你的正文，你什么感觉？PR 就是"我改好了，你帮我看看再合并"。这个"看看"的过程叫 Code Review（代码审查），是团队协作中防止事故的关键环节。
你可能觉得"我们就两个人，还需要这么正式吗？"——需要的。不是因为流程本身有多重要，而是因为另一双眼睛真的能发现你自己看不到的问题。你写了三天的代码，脑子里全是实现细节，很容易对自己的代码产生"盲区"——你觉得逻辑没问题，但朋友一看就发现你漏了一个边界情况。
PR 的价值不只是"多一双眼睛"。朋友可能发现你遗漏的边界情况或潜在 bug——比如推荐算法没有处理用户没有评分记录的情况。通过 Review 别人的代码，朋友也了解了推荐功能的实现，这是知识共享——如果小明哪天不在，朋友也能维护推荐功能，因为他在 Review 的时候已经读过这些代码了。
所有关于这段代码的讨论都留在 PR 页面上，以后可以回溯"当时为什么这么写"。三个月后你看到一段奇怪的代码，不知道为什么要这么写，翻一下当时的 PR 讨论就能找到答案。
对于个人项目，PR 也有价值——它让你在合并前有一个"暂停、回顾"的机会。你可能在分支上连续开发了好几天，PR 的 diff 视图能帮你从全局视角审视这些修改，发现自己在细节中遗漏的问题。在发起 PR 之前，你还可以让 Claude Code 先做一轮 Self-Review——检查逻辑错误、安全隐患、性能问题。这样提交给朋友审查的代码质量更高，朋友也更愿意帮你 Review。
朋友打开 PR 页面，看到了小明改了哪些文件、每个文件具体改了哪几行。他可以在某一行代码下面留言："这里的推荐算法没有处理用户没有评分记录的情况。"小明看到评论，修改代码，再次提交推送。PR 会自动更新，朋友可以看到新的修改。这个来回的过程可能会持续几轮——朋友提出问题，小明修改，朋友再看，直到双方都满意。这不是在浪费时间，而是在提高代码质量。很多 bug 就是在这个过程中被发现的，而不是上线之后被用户发现。
朋友确认没问题后，点击 Merge pull request。推荐功能的代码被合并到 main 分支，功能正式上线。合并后，GitHub 会提示你是否要删除这个分支。点击 Delete branch 就行——分支的使命已经完成，它的所有代码变更已经合并到了 main 里。别舍不得删，分支是廉价的，用完就扔。PR 页面上保留了所有代码变更和讨论记录，不会因为删除分支而丢失。以后你想回顾"推荐功能当时是怎么实现的"，翻这个 PR 就行。
完整流程图：
main ──────────────────────────────────────── main (包含推荐功能)
│ ↑
└── feature/recommend ──→ 开发 ──→ PR ──→ Review ──→ Merge你可能会想：我一个人开发，没有朋友 Review，还需要分支和 PR 吗？
答案是看情况。如果你只是在做一个小项目，直接在 main 上开发、提交、推送，完全没问题。很多个人项目从头到尾都在 main 上开发，也运行得很好。
但当你的项目开始变复杂——比如你想同时尝试两个不同的方案，或者你想在不影响线上版本的情况下做一次大重构——分支就变得有用了。
举个具体的场景：你的项目已经部署上线了（第十二章会讲部署），用户正在使用。你想加一个新功能，但这个功能需要改好几天。如果你直接在 main 上改，改到一半的代码可能会被部署上线——半成品的功能展示给用户，体验很差。但如果你在分支上开发，main 始终保持稳定可部署的状态，新功能开发完、测试通过后再合并到 main，用户看到的永远是完整的功能。
一个折中的做法：日常小修改直接在 main 上提交，大功能或实验性改动开分支。不需要一开始就严格执行完整的 PR 流程，等你和朋友开始协作时再引入。
Git 的工作流是渐进式的——先养成频繁提交和及时推送的习惯，等这两个习惯稳定了，再引入分支和 PR。不要试图一步到位，那样只会让你觉得 Git 很麻烦。
当你和朋友的协作进入正轨，日常开发会形成一个固定的节奏。每天开始工作时先拉取最新代码，确保你的本地是最新的。然后创建功能分支，隔离你的工作。在分支上开发，小步快跑，频繁 commit。开发到一个阶段就推送到 GitHub，既是备份也是让朋友看到进展。功能完成后创建 PR，请求朋友审查。Review 通过后合并到主分支，最后删除功能分支保持整洁。
开始工作
↓
拉取最新代码（pull）—— 确保你的本地是最新的
↓
创建功能分支 —— 隔离你的工作
↓
开发 + 提交 —— 小步快跑，频繁 commit
↓
推送到 GitHub（push）—— 备份 + 让别人看到
↓
创建 PR —— 请求审查
↓
Review + 合并 —— 代码进入主分支
↓
删除功能分支 —— 保持整洁这个节奏不是死规矩。个人项目可以简化——不一定每次都开分支、创建 PR。但当你和别人协作时，这套流程能帮你避免大部分"代码打架"的问题。刚开始可能觉得步骤有点多，但用几次就会变成习惯。就像开车——刚学的时候觉得要同时注意方向盘、油门、刹车、后视镜，手忙脚乱。开熟了之后这些动作都是自动的，你甚至不会意识到自己在做这些事。Git 工作流也是一样，用熟了之后"pull → 分支 → 开发 → PR → 合并"就是你的肌肉记忆。
分支让你安全地实验新功能，PR 让你在合并前获得审查，跨平台配置让不同系统的协作者能顺畅合作。这套工作流的核心不是记住命令，而是建立一个习惯：改之前开分支，合之前做 Review。
下一章：代码在 GitHub 上了，怎么让用户访问到？第十二章：无服务器部署与 CI/CD 自动化 带你把项目部署上线。