分支乱，多半不是工具的问题，而是"哪段代码该待在哪条线上"没有共识。主干、发布、热修三条线只要边界清楚，五个人和五十个人的团队都能少走回头路。
一、先定一条真相线：主干
主干（main）是全队唯一的事实来源：这里的代码永远可构建、可发布、可回溯。做不到这一点，后面所有约定都只是纸上规矩。
- 功能分支要短、合并要勤，尽量一天内合回主干
- 不在主干上直接开发新功能，但也别让分支活过一周
- 主干上的每一次提交都应能通过构建与基础用例
二、发布分支：给"稳定"留一个位置
上线不是一次动作，而是一段时间。冻结之后主干还在往前走，稳定就需要单独的位置来承载。
| 分支 | 用途 | 生命周期 |
|---|---|---|
| main | 唯一真相线，始终最新 | 长期 |
| feat/* | 单个功能开发 | 一周以内 |
| release/* | 发布冻结，只接收缺陷修复 | 冻结到上线后一个版本 |
| hotfix/* | 线上紧急修复 | 数小时至一天 |
三、热修怎么不污染主线
线上出问题时最忌讳"哪里方便改哪里"。热修必须从发布点拉分支，改完之后同时回到两条线上。
- 从 release 分支或上线 tag 拉 hotfix/*，不要在本地工作区直接改
- 修复内容先合回主干，再合回发布分支，避免下次发版又把问题带回来
- 每次热修都补一个能复现问题的用例
- 修完立即打 tag，记录版本号与影响范围
四、合并冲突的日常约定
冲突不是能力问题，是节奏问题。同步得越勤，冲突就越小。
- 每天开始工作前同步一次主干
- 冲突在本地解决完再推，不要把半成品推上去让别人猜
- 合并前跑一遍完整构建，别只跑自己改动的那部分用例
- 改动面大的一方负责跟进收尾，避免互相等
五、小团队最容易犯的三个错
- 把主干当试验田：今天能跑明天崩，发布前才发现
- 长期分支各写半年：合并那天等于重写一次
- 只在嘴上约定：换个人接手，规则立刻失效
把三条线的边界写进仓库说明，比开三次会更管用。规则越短越容易被遵守——一页纸足矣。
#分支管理#发布流程#研发规范#代码评审
