分支模型不需要复杂到让人害怕，但必须让团队知道：新功能从哪里开、修复提交到哪里、什么时候合并、谁负责验证、上线后如何回滚。小团队尤其适合轻量但稳定的节奏。
主干保持可发布
无论叫 main、master 还是 release，主干都应该尽量保持可构建、可测试、可发布。日常功能从主干切短分支，完成后尽快合并，避免长期分支积累大量冲突。
如果功能还没准备好，可以用配置开关、权限开关或页面入口控制，而不是让分支长期漂在外面。长期分支会让集成成本变成隐藏债务。
提交粒度服务审查
提交不必小到每改一行就 commit，但要能让别人理解意图。一个提交最好只表达一个主题：修一个 bug、加一个接口、调整一个页面或补一组测试。提交信息用中文说明业务变化，比纯英文模板更适合个人项目追溯。
合并前看三件事：有没有无关文件、有没有调试输出、有没有缺少验证。前端还要注意空链接、假链接和 undefined 链接；后端要注意入参校验和写操作审计。
发布分支只收敛风险
进入发布分支后，原则上只接收阻塞上线的问题修复。不要在发布分支里继续塞新功能，否则测试范围会不断扩张。发现必须延期的功能，就从发布分支摘掉，回到后续迭代处理。
紧急修复可以从线上版本切 hotfix，修完后同时合回主干，避免线上修复只存在于临时分支。
每次合并都要能验证
最小验证可以是测试、构建、类型检查、页面 smoke test 或接口 smoke test。没有验证的分支合并，等于把问题交给下一个人发现。
分支协作的目标不是追求复杂流程，而是让代码变化有节奏、有记录、有回退路径。小团队越轻量，越需要把这几个关键动作固定下来。
正文完
