版本命名规范
版本号格式：X.Y.Z
- X 表示主版本号，当 API 的兼容性变化时，X 需递增。
- Y 表示次版本号，当增加功能时(不影响 API 的兼容性)，Y 需递增。
- Z 表示修订号，当做 Bug 修复时(不影响 API 的兼容性)，Z 需递增。
版本一经发布，不得修改其内容，任何修改必须在新版本发布,版本后可加修饰词，常用修饰词：
- 开发常用
- Snapshot：版本代表不稳定、尚处于开发中的版本
- Alpha: 内部版本
- Beta: 测试版
- Demo: 演示版
- 发布常用
- M：M版本则代表里程碑版(M是Milestone的意思）具有一些全新的功能或是具有里程碑意义的版本
- GA: GA版本则代表广泛可用的稳定版(General Availability)
- RC: 候选版本，即将作为正式版发布(Release Candidat)
- RELEASE: 发行版
- SR: 修正版, 发行版本发行bug修复后发布的版本
Git 分支命名规范
| 分支 | 命名 | 说明 |
|---|---|---|
| 主分支 | master | 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布 |
| 发布版本 | release_* | 发布定期要发布的功能或时间点版本，出系统测试、集成测试版本 |
| 开发分支 | dev | 开发分支，永远是功能最新最全的分支，出开发测试版本 |
| 功能分支 | feature_* | 新功能分支，某个功能点正在开发阶段 |
| 修复分支 | bug_* | 修复发布版本的bug |
分支合并顺序：
-
feature -> dev -> release -> master
开发过程中各功能开发完成后合并到开发分支（dev），开发测试完成后，合并到release分支做系统测试和集成测试，测试完成，合并到master分支做终测，并发布
-
bug -> release -> master
开发阶段的bug不需要单独分支处理。在release分支或master的测试bug,开bug分支修复，修复完成后合并到release分支做测试和集成测试，测试完成，合并到master分支做终测，并发布