[Git][分支设计规范]详细讲解

---

0.概览

• 以下是常用的分支和环境的搭配，可视情况而定不同的策略

  分支	名称	适用环境
  master	主分支	生产环境
  release	预发布分支	预发布/测试环境
  develop	开发分支	开发环境
  feature	需求开发分支	本地
  hotfix	紧急修复分支	本地

• 以下介绍的模型，是企业级常用的一种Git分支设计规范：Git Flow模型
  

---

1.master分支

• master为主分⽀，该分⽀为只读且唯⼀分⽀
  • ⽤于部署到正式发布环境，⼀般由合并release分⽀得到
• 主分⽀作为稳定的唯⼀代码库，任何情况下不允许直接在master分⽀上修改代码
• 产品的功能全部实现后，最终在master分⽀对外发布
  • 所有在master分⽀的推送应该打标签 (tag)做记录，⽅便追溯
• master分⽀不可删除

---

2.release分支

• release为预发布分⽀，基于本次上线所有的feature分⽀合并到develop分⽀之后，基develop分⽀创建，可以部署到测试或预发布集群
• 命名以release/开头，建议的命名规则：release/version_publishtime
• release分⽀主要⽤于提交给测试⼈员进⾏功能测试，发布提测阶段，会以release为基准进⾏提测
• 如果在release分⽀测试出问题，需要回归验证develop分支是否存在此问题
• release分⽀属于临时分⽀，产品上线后可选删除

---

3.develop分支

• develop为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀
  • 始终保持最新完成以及bug修复后的代码，可部署到开发环境对应集群
• 可根据需求⼤⼩程度确定是由feature分⽀合并，还是直接在上⾯开发(⾮常不建议)

---

4.feature分支

• feature分⽀通常为新功能或新特性开发分⽀，以develop分支为基础创建feature分支
• 命名以feature/开头，建议的命名规则：feature/user_createtime_feature
• 新特性或新功能开发完成后，开发⼈员需合到develop分⽀
• ⼀旦该需求发布上线，便将其删除

---

5.hotfix分支

• hotfix分⽀为线上bug修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏bug修复
  • 当线上出现紧急问题需要⻢上修复时，需要基于master分⽀创建hotfix分⽀
• 命名以hotfix/开头，建议的命名规则：hotfix/user_createtime_hotfix
• 当问题修复完成后，需要合并到master分⽀和develop分⽀并推送远程
  • ⼀旦修复上线，便将其删除