为什么分支要映射环境
分支规范的价值不是让提交历史看起来整齐，而是让代码在不同阶段有明确的停靠点。生产环境、测试环境、需求开发和线上修复面对的是完全不同的风险，混在一起就会出现“测试代码误上生产”“修复被需求覆盖”“多人同时改 beta 不知道谁负责”的问题。
一个小团队最实用的模型，是把 master 作为生产事实，beta 作为测试集成，dev/* 作为需求开发，fix/* 作为线上修复。这样每次代码移动都带着语义，评审、部署和回滚也有共同语言。
- master 只承载已经上线或即将上线的稳定代码。
- beta 用于集成测试，不直接作为长期开发分支。
- dev/feature-name 从 master 拉出，完成后合并到 beta 提测。
- fix/issue-name 从 master 拉出，修复后优先合并 beta 验证，再回 master。
一次需求从开始到上线
需求开始时，开发者从 master 拉出 dev/xxx 分支。这个动作意味着它继承的是线上稳定版本，而不是其他半成品需求。开发完成后先自测，再发起合并到 beta。beta 部署到测试环境后，测试只需要确认这个需求以及 beta 上已经合并的需求集合。
上线时，从通过验收的提交合并回 master，并打 Tag 或记录发布版本。上线后 master 继续作为新的事实源。这样的流程看起来多一步，但它把“谁的代码在哪个环境”这件事说清楚了。
- 需求分支命名最好能看出模块和目标，例如 dev/customer-import。
- 提交信息使用 feat、fix、refactor、docs 等语义前缀。
- 合并前至少跑 lint、test、build 三类检查。
- 上线记录要包含分支、提交、版本、执行人和回滚方案。
容易踩的坑
最常见的问题是把 beta 当成公共开发分支。短期看大家都很方便，长期看它会变成一个没人说得清的混合态。另一个问题是修复线上问题时直接改 beta，结果修复无法干净回到 master，或者上线时带入未验收需求。
分支规范越简单，越要坚持边界。团队可以根据规模扩展 release/*、hotfix/*，但基础原则不变：生产事实要稳定，测试集成要可解释，开发分支要短生命周期。
- 禁止在 master / beta 直接开发。
- 禁止把未验收需求偷偷带入上线包。
- 修复分支必须能追溯到问题单或事故记录。
- 长期分支需要定期清理，避免成为第二个 beta。
知识库里的标准命令流
知识库里对分支环境映射的定义很明确：master、beta、dev/*、fix/* 不是随意命名，而是分别对应生产、测试、需求开发和缺陷修复。真正重要的是合并方向。分支策略一旦允许 beta 反向污染 master 或 dev，就会把测试环境里的半成品带进生产链路。
更稳的命令流是：从 master 拉 dev/* 或 fix/*，开发过程中持续同步 master，提测时合并到 beta，测试通过后再合并 master 并打 Tag。上线之后根据需要由 master 回写 beta，让测试环境重新靠近生产事实。
- 需求分支：master -> dev/{日期}/{需求} -> beta -> master。
- 修复分支：master -> fix/{日期}/{问题} -> beta 验证 -> master。
- 环境同步：master 有更新时，开发分支及时合并 master。
- 禁止方向：不要把 beta 合并回 dev/*、fix/* 或 master。
分支命名也是沟通接口
分支命名不是给 Git 看，而是给人看。一个好的分支名应该回答三个问题：这是需求还是修复，什么时候创建，处理什么事情。知识库中的后端规范建议使用 dev/{日期}/{需求} 和 fix/{日期}/{需求}，并保持全小写路径化格式。
路径化命名能让 Jenkins、GitLab、发布脚本和人工评审都更容易识别上下文。它也方便之后按日期和需求回查变更。
- dev/2026-05-18/customer-import 表示客户导入需求。
- fix/2026-05-18/order-status 表示订单状态缺陷修复。
- 分支名避免中文、空格和过长描述。
- 前后端如果协作同一需求，建议使用同一需求段。
质量门禁如何接入这套流程
分支只解决代码流向，不能替代质量检查。知识库里的质量门禁强调 lint、type-check、test、build 应该进入提交和合并阶段。最小可行做法是本地提交前跑基础检查，PR 或合并 beta 前由 CI 跑完整检查。
当 CI 失败时，不要靠人工口头承诺先合并。门禁的意义就是把低级错误挡在主干之外。
- 前端：lint、type-check、unit test、build。
- 后端：语法检查、单元测试、数据库迁移检查、接口冒烟。
- 合并 beta 前要有需求自测记录。
- 合并 master 前要有验收结论和回滚说明。