第 7 章 分支与 PR：正式的协作流程

第一册说过分支是"平行宇宙"。这一章把完整流程走一遍——它同时也是你和 Claude Code 网页版协作的标准流程。

开宇宙：git switch -c feat-search（新建并切换到名叫 feat-search 的分支；旧写法 git checkout -b 同义，AI 两种都会用）。此刻左下角状态栏的分支名变了——你已站在平行宇宙里，怎么折腾都不影响 main。在宇宙里干活：正常的改、add、commit。把宇宙推上云：git push -u origin feat-search。发起合并申请：刷新 GitHub，页面顶端会出现一条黄色提示"Compare & pull request"，点它，写清这个分支做了什么，创建 PR（Pull Request）——一份正式的"请过目"。审查：PR 页面的 Files changed 标签页就是全部改动的红绿差异，可以逐行留言。裁决：满意点 Merge，宇宙并入主线；随后删掉这条已完成使命的分支（GitHub 会顺手给你删除按钮）。回家：本地切回 main（git switch main），git pull 把合并成果拉下来。

一个人开发，为什么也要走这套？两个理由。其一，PR 是强制的"过目"环节——直接推 main，改动就无声无息进了主干；走 PR，你必须把全部差异正眼看一遍，这对审查 AI 的产出尤其珍贵。其二，这就是收货流程：第 3 章说过，Claude Code 网页版交活的方式就是一条分支加一个 PR——你在本章练的每一步，都是在练怎么收它的货。分支起名有个通行小惯例：feat- 开头是新功能，fix- 开头是修复，一眼可读。

关键领悟

main 是正式出版物，分支是草稿纸，PR 是编辑审稿。让一切改动先当草稿，被看过，再出版。

试一试

下次让 AI（插件或网页版皆可）改任何东西时，要求它"开分支、提 PR"，然后你在 GitHub 网页上完成一次正式审查与合并。