产品版本递增规范及代码分支管理要求
条评论到目前为止，关于数字货币交易平台的项目总共有3个，分别是前台页面项目、后端接口和后台管理的项目、撮合服务项目。后续可能还会有更多的项目要进行维护。
1. 代码版本递增规范
现在对这些项目的版本号进行规范管理，每次项目版本号的迭代，都需要管理人员统一商定，并严格按照以下要求来制定版本号。
版本格式：v + 主版本号.次版本号.修订号，比如 v1.0.1，注意v小写。版本号中的数字最多不能超过3位。版本号递增规则如下：
主版本号：当做了不兼容的 API 修改，或者重大架构更新时。
次版本号：当做了向下兼容的功能性新增、更新时。
修订号：当做了向下兼容的bug修复时。
2. 代码分支管理要求
鉴于之前的代码合并过程中，发生了部分未完成的代码被合并到开发分支的情况，导致了代码无法进行快速拆分和版本标记，所以以后要求所有开发人员及管理人员必须严格遵照Git Flow来做代码分支的管理。
以下关于本团队代码分支管理要求的内容，均参照于这里关于Git Flow的描述：Git三大特色之WorkFlow(工作流)
2.1 长期分支
一个项目中，要保证2个长期存在的分支，分别为master和develop分支。这2个分支均设为保护分支（只有项目中的Master角色才能允许其他分支的代码被合并到此分支上）。master分支主要用于标记版本号（即添加Tag）。develop分支用于日常的开发内容合并。develop是master下的分支。
2.2 辅助分支
除了2个长期存在的分支外，还要有3类辅助分支，辅助分支在被合并后可以删除。分别为Feature Branch、Release Branch 和 Hotfix Branch。
2.2.1 Feature Branch
feature分支用来做一个模块/功能开发或更新，分支命名要求：feature/{功能模块简称标识}，不要和其他类型的分支命名弄混淆就好，举个坏例子，命名为 master 就是一个非常不妥当的举动。
该分支上的功能完成后，申请合并到 develop 分支，并选择被合并后删除该分支。
如果一个功能模块只有一个开发人员来进行，那么该开发人员可以在该feature分支上直接进行开发。
如果一个功能模块由多个开发人员来进行，那么为了避免代码冲突和覆盖，每个开发人员需要在该feature分支上检出各自的分支，命名要求：feature/{功能模块简称标识}/{开发人员姓名全拼}，开发完毕后将各自分支上的代码合并到feature分支上。
2.2.2 Release Branch
release分支用来做版本发布的预发布分支，分支命名要求：release/{预发布的版本号}。例如在软件 v1.0 版本的功能全部开发完成，并且已经被合并到develop分支后，那么从develop分支检出release/v1.0分支，将release/v1.0分支上的代码部署到测试服务环境中。测试过程中出现的问题，可在该release分支上进行修改提交。涉及多个开发人员的话，需要在该release分支上检出各自的分支进行修改，命名要求：release/v1.0/{开发人员姓名全拼}。
测试完毕准备发布的时候，将该release分支上的代码分别合并到 master 和 develop分支，合并到master 分支后要打上对应版本标签 v1.0，同时写明功能模块新增/更新的详细描述。记住，待合并到master和develop分支之后，删除该release分支。
release分支的好处是，在测试的时候，不影响下一个版本功能的并行开发。
2.2.3 Hotfix Branch
hotfix分支是用来做线上的紧急 bug 修复的分支，命名要求：hotfix/{bug简称标识}。当线上代码出现了问题，从master分支直接检出hotfix分支，然后在该hotfix上修复bug。涉及多个开发人员的话，需要在该hotfix分支上检出各自的分支进行修改，命名要求：hotfix/{bug简称标识}/{开发人员姓名全拼}。
待问题修复后，将hotfix分支中的代码合并到 master 和 develop 分支，全部合并完成后删除该hotfix分支。注意，合并到 master 分支的时候，要打上修复后的版本标签，比如从v1.0 -> v1.0.1，同时要写明修复bug的详细描述。
2.3 Git Flow示意图
上述关于长期分支和辅助分支之间的工作切换流程，可以总结为下面的一张图。
