分支命名规范.md 3.8 KB
分支命名规范
分支命名，主要有两种格式。一种是根据产品原型版本号确定命名，一种是特殊分支命名；
根据原型版本号命名
代码版本命名规范的基础是产品原型指定的迭代版本号，基本格式是 v[主版本号].[次版本号].[修订版本号]]_[后缀信息]。
版本号遵循“语义化版本”的规则。版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
后缀信息主要是用于追加不同的业务、特定的功能标记或其他开发信息等。
目前常见的后缀信息主要有两种：
根据需求业务区分。
互联网医院的需求业务，不需要使用后缀标记，直接采用产品确定的原型版本号。如果是合作医院定制的需求，根据以下规则使用后缀：
nfby：只在南方医科大学南方医院白云分院上线的需求；nfth: 只在南方医院太和分院上线的需求；
如果是同一个需求业务，在多个医院要同时开发同时上线，那么只需要使用一个版本号即可，优先级：互联网医院 > 南方医科大学南方医院白云分院 > 南方医院太和分院。
举例：病案邮寄需求，同时在互联网医院、南方医科大学南方医院白云分院和南方医院太和分院开发上线，产品提交的需求文档有三个：互联网医院v4.4.0（病案邮寄）、南方医科大学南方医院白云分院v1.8.5（病案邮寄）、南方医院太和分院v2.3.5（病案邮寄），那么这个需求版本就采用 v4.4.0；体检预约需求，在南方医科大学南方医院白云分院上线，产品提交的需求文档为南方医科大学南方医院白云分院v1.9.0（体检预约），需求版本采用 v1.9.0_nfby。
特定的开发标记，例如已上线的版本需要紧急修复，添加
hotfix后缀。
特殊的分支命名
根据开发习惯约定的特殊命名：
test: 测试分支，一般是 qa 环境的构建分支；
dev: 开发分支，个人进行功能开发的分支；
publish: 线上发布分支，是生产环境的构建分支；
master: 主分支，一般不允许直接在该分支上进行开发；
hotfix: 修复分支，主要是针对已上线的功能出现严重缺陷需要紧急修复，或者修复的缺陷跟历史版本没有强关联性的情况下使用；如果能追溯缺陷的关联版本，还是需要按照上面的根据原型版本号命名规范，用版本号 +
_hotfix后缀去命名分支；feat_[功能英文描述]: 进行特定功能需求开发的分支，对于无需求版本的开发功能，统一使用这种格式的命名规范；
注意事项
对于前后端项目，同一个需求版本，命名必须保持一致；对于特殊的分支命名，也要求统一。
master 分支原则上禁止直接在其上开发和提交，但也有例外：如单人专门负责的模块，不涉及协作（但多版本迭代仍然需要开启多分支）；还有一些特殊项目，如 grpc-services-def，这个项目是多个项目公用的 grpc 定义文件，统一在 master 分支开发，遇到冲突必须协作解决。
由于历史原因，前端有部分项目的分支命名存在混乱，需要进一步规范化。
在以前的开发过程中，难免会有一些没有明确需求版本号的开发需求，这时候会采用业务或功能名称的英文作为分支名。但这种行为并不规范，以后的开发中必须禁止；统一使用
feat_前缀命名。