[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分⽀并推送远程 - ⼀旦修复上线，便将其删除