分支命名规范

分支命名，主要有两种格式。一种是根据产品原型版本号确定命名，一种是特殊分支命名；

根据原型版本号命名

代码版本命名规范的基础是产品原型指定的迭代版本号，基本格式是 v[主版本号].[次版本号].[修订版本号]]_[后缀信息]。

版本号遵循“语义化版本”的规则。版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。

后缀信息主要是用于追加不同的业务、特定的功能标记或其他开发信息等。

目前常见的后缀信息主要有两种：

根据医院业务区分，例如针对南方医院白云分院定制的需求，统一使用 nfby 后缀；

太和和互联网平台的需求业务，不需要使用后缀标记。

如果是同一个需求业务，在多个医院要同时开发同时上线，那么只需要使用一个版本号即可。
特定的开发标记，例如已上线的版本需要紧急修复，添加 hotfix 后缀。

举例：

例如原型文档是 南方医院太和分院/v1.8.5（MRI优化），分支的命名是 v1.8.5；原型文档是 南方医科大学南方医院白云分院v1.3.1（订餐服务优化），在开发的时候，分支的命名为 v1.3.1_nfby。

特殊的分支命名

根据开发习惯约定的特殊命名：

test: 测试分支，一般是 qa 环境的构建分支；
dev: 开发分支，个人进行功能开发的分支；
publish: 线上发布分支，是生产环境的构建分支；
master: 主分支，一般不允许直接在该分支上进行开发；
hotfix: 修复分支，主要是针对已上线的功能出现严重缺陷需要紧急修复，或者修复的缺陷跟历史版本没有强关联性的情况下使用；如果能追溯缺陷的关联版本，还是需要按照上面的根据原型版本号命名规范，用版本号 + _hotfix 后缀去命名分支；
feat_[功能英文描述]: 进行特定功能需求开发的分支，对于无需求版本的开发功能，统一使用这种格式的命名规范；

注意事项

对于前后端项目，同一个需求版本，命名必须保持一致；对于特殊的分支命名，也要求统一。
master 分支原则上禁止直接在其上开发和提交，但也有例外：如单人专门负责的模块，不涉及协作（但多版本迭代仍然需要开启多分支）；还有一些特殊项目，如 grpc-services-def，这个项目是多个项目公用的 grpc 定义文件，统一在 master 分支开发，遇到冲突必须协作解决。
由于历史原因，前端有部分项目的分支命名存在混乱，需要进一步规范化。
在以前的开发过程中，难免会有一些没有明确需求版本号的开发需求，这时候会采用业务或功能名称的英文作为分支名。但这种行为并不规范，以后的开发中必须禁止；统一使用 feat_ 前缀命名。