工程与协作
分支Branch
你可能会问
分支到底是什么？为什么不直接在主线上改？
简单来说
与主线隔离的开发路径，适合独立完成和验证一项修改。
直接改主线开分支再改实验和主线，要不要隔离
急 bug · 被卡死急 bug · 随时能修平行推进，互不绑架
01 · 先这样理解
把抽象概念放进真实场景
与主线隔离的开发路径，适合独立完成和验证一项修改。
换个角度想分支像做菜前先盛出一小碗试味：调料在小碗里随便试，锅里的菜始终能上桌。试对了，再把做法用回锅里。
02 · 点击演示
AI 重构到一半，线上要修急 bug，怎么办？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 这一步不存在——
所有修改直接落在主线上开出分支 rewrite-pay
主线复制出一条平行路径
- 主线上
支付模块改到一半 · 跑不起来急 bug偏偏这时来了！分支上支付模块放手重构中主线原样 · 随时可用 想先修急 bug
主线全是半成品，发不了版
急 bug 另开小分支，修好先上线
重构分支测试跑绿
- 进退两难撤掉半天的重构，才能腾出手修 bug主线被半成品绑架了各自归位急 bug 已上线，重构验证完汇入主线隔离得开，才推进得快
1 / 4
Fork · 从主线开出一条分支
03 · 放进真实任务
什么时候会遇到它
给 AI 一块沙盒
让 Agent 在分支上干活，主线永远是稳的。
多任务并行
一人修 bug 一人做新功能，各自分支互不干扰。
敢做大实验
大重构失败了就弃掉分支，成本几乎为零。
04 · 想一想
用一个问题检查理解
你想让 AI 重写整个支付模块，同时线上随时可能要修紧急 bug。怎么安排？
查看答案
重写放在一条功能分支上慢慢做；紧急 bug 从主线另开一条小分支，修完先合并上线。两件事互不阻塞——这正是分支存在的意义。
最容易踩的坑
分支不是开得越久越好。拖几周不合并，主线早变了样，合并冲突会让你怀疑人生——小步开、尽快合。