工作机制
工程师从主线创建分支，在数天或数周内提交功能，完成后发起合并请求。CI 在分支上运行，评审者查看差异，最后通过合并提交或压缩提交回到主线。发布前还可能从主线切出发布分支做稳定化。
适用场景与取舍
功能分支适合协调式发布、集成频率较低的团队，以及必须在某个日期前保密、不能进入主线的改动。它给每个变更独立工作区和自然的评审边界。与主干开发相比，它优先隔离而非集成频率：改动大而风险高时有帮助，但分支存活数周就会带来痛苦。分支越久，与主线漂移越多，合并冲突会从文本冲突变成语义冲突。
具体示例
团队在 feature/billing-v2 上开发新账单页面三周，期间其他人修改了共享的定价模块。合并时出现六十处冲突，并暴露出对税费计算的错误假设，发布因此延迟两天。
常见误解与关联概念
功能分支本身没有错，风险在分支寿命而非分支的存在。分支合并也不等于功能可以安全暴露，部署与发布是两个独立决策；此外，分支不能替代主线上的持续集成。主干开发通过每日集成避免长期分叉，代码评审是任何分支模型的合并门禁，渐进式交付负责让合并后的功能逐步放量。