| 编写人 | 版本 | 时间 | 备注 |
|---|---|---|---|
| 张伟 | 1.0.0 | 2019-05-10 | 初版 |
版本号命名方式：主版本号 . 次版本号 . 修正版本号 [-版本号修饰]
- 主版本号：当你做了不兼容的 API 修改，存在向下不兼容
- 次版本号：当你做了向下兼容的功能性新增，向下兼容的新增或修改
- 修正版本号：当你做了向下兼容的问题修正
- 版本号修饰：主要标识版本的使用范围，比如使用对象、维护时长
软件开发管理工作流：Git Flow
- master分支：最新的保证可部署的正式版本
- develop分支：最新的合并后开发版本
- feature分支：功能开发
- release分支：发布版本号与已知问题少量修改
- hotfix分支：修复已发布的版本问题
1.主版本号、次版本号、修正版本号命名只能使用数字，数字只能大于等于0，数值只能递增并且禁止在版本号数字前补0。
2.版本发布以后禁止修改软件内任何内容，如果有修改必需以新版本发布。
3.当主版本号为0时，软件被视为不稳定阶段，一切功能和接口都可能更改。当主版本号升级不为0后，软件视为稳定版本，之后的修改会基于当前的功能。
4.增加了向下兼容的新功能时或功能标记弃用时，需要增加次版本号，只有在的基础上，次版本号增加的时候，修正版本号需要归零。
5.进行了向下兼容的对已有功能的bug修复或者功能修正的时候，需要增加修正版本号。
6.主版本号增加时，需要将次版本号、修正版本号都归零。
7.版本号修饰主要用于：该版本有不同的发布范围和状态，支持维护的时间，可能的变更风险等。
8.版本号修饰一般有以下方式：
- alpha: 内部测试版本，BUG 较多，一般用于开发人员内部交流
- beta: 测试版，BUG 较多，一般用于小范围测试，并向开发人员反馈
- rc: release candidate，即将作为正式版发布，正式版之前的最后一个测试版。
- r/release/或干脆啥都不加: 最终释放版，用于一般用户
- lts: 长期维护，指定版本维护时间，会修复所有在这个版本中发现的 BUG
版本号命名示例：0.1.1, 1.0.0 , 1.11.2 , 2.3.0-alpha , 2.3.0-beta
1.master分支和develop分支是随着项目生命周期长期存在的分支，绝对不被删除。
2.master分支维护的是最新的可部署版本，并且不允许直接对该分支进行代码的提交和修改，只允许发布时从其他分支合并进入，合并以后需要发布对应版本号的git标签。
3.develop分支维护的是最新的开发过程中的代码，也不允许直接对该分支进行代码的提交和修改，只能从相关的feature分支中合并进入。
4.feature分支是实际开发的工作空间，每个需要开发的feature会从当前的develop分支中新建出对应的feature，在feature分支中进行开发与提交，开发完毕后通过合并请求合并到develop分支中。
5.release分支只处理版本发布前的准备工作，不允许进行需求变更和功能变更，只允许修改部分提测后暴露的bug。
6.hotfix分支用于进行已经发布的版本的修复工作，如果某个发布版本产生了漏洞需要尽快修复，将会在已经发布的版本基础上创建hotfix分支，并且在该分支下修复问题后，发布更新的版本（修正版本号增加）。
- 语义化版本控制的规范（语义化版本 2.0.0）
- A succdessful Git branching model
- Git 的使用