# 分支命名规范

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


## <span id="name-by-version">根据原型版本号命名</span>

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

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

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

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

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

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

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

    如果是同一个需求业务，在多个医院要同时开发同时上线，那么只需要使用一个版本号即可。

2. 特定的开发标记，例如已上线的版本需要紧急修复，添加 `hotfix` 后缀。

举例：

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


## 特殊的分支命名

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

- test: 测试分支，一般是 qa 环境的构建分支；

- dev: 开发分支，个人进行功能开发的分支；

- publish: 线上发布分支，是生产环境的构建分支；

- master: 主分支，一般不允许直接在该分支上进行开发；

- hotfix: 修复分支，主要是针对已上线的功能出现严重缺陷需要紧急修复，或者修复的缺陷跟历史版本没有强关联性的情况下使用；如果能追溯缺陷的关联版本，还是需要按照上面的[根据原型版本号命名规范](#name-by-version)，用版本号 + `_hotfix` 后缀去命名分支；

- feat_[功能英文描述]: 进行特定功能需求开发的分支，对于无需求版本的开发功能，统一使用这种格式的命名规范；



## 注意事项

- 对于前后端项目，同一个需求版本，命名必须保持一致；对于特殊的分支命名，也要求统一。

- master 分支原则上禁止直接在其上开发和提交，但也有例外：如单人专门负责的模块，不涉及协作（但多版本迭代仍然需要开启多分支）；还有一些特殊项目，如 [grpc-services-def](https://gogs.ywtinfo.com/ywt/grpc_services_def)，这个项目是多个项目公用的 grpc 定义文件，统一在 master 分支开发，遇到冲突必须协作解决。

- 由于历史原因，前端有部分项目的分支命名存在混乱，需要进一步规范化。

- 在以前的开发过程中，难免会有一些没有明确需求版本号的开发需求，这时候会采用业务或功能名称的英文作为分支名。但这种行为并不规范，以后的开发中必须禁止；统一使用 `feat_` 前缀命名。