名词约定
对外的产品号是x.y。git中分支的版本号是x.y.hotfix_times（x.y = x.y.0）。
分支是可以反复提交的。tag是不能再被提交的。
原则：开发过程中使用分支，一旦测试人员验收通过，就打tag。
分支约定
我们使用了简化版的gitflow，如下
- master 当前产品的最新版本的分支
- tag: v1.0或v1.0.1 每次发布时的版本，会和master合并。要发布到生产环境
- qa 多个feat_*会合并到这里，测试人员使用
- feat_*：功能分支，对应每次迭代，完成后合并到qa。
- hotfix_at_* 热修分支（名字中有_at_，因为hotfix_v1.0有歧义，它可能是热修v0.9，也有可能是热修v1.0，加上_at_就说明是热修v1.0），场景是生产环境出现问题，拉取对应tag为hotfix_at_*，完成后会推送到新tag，并累加最后一位小版本号。
举例说明
新开工程，要开发v0.1功能。
此时会新建feat_v0.1分支。开发自测完毕后推到qa分支，测试人员验收qa分支。有问题时开发人员修改feat_v0.1，自测完毕后合并到qa分支，测试人员再去验收qa分支。
验收完毕后将qa分支推送新tag v0.1，并将qa分支合并到master。
cd-ci拉取master分支并构建。
此时要开始v0.2功能，就新建feat_v0.2分支，开发自测完毕后推到qa分支，测试人员验收qa分支。
此时生产环境有bug，就根据v0.1 tag拉取新分支hotfix_at_v0.1，并修改代码，修改后让qa单独验收此分支，无误后推到新tag v0.1.1，并将该分支合并到master。cd-ci拉取master分支并构建。
此时qa验收通过，则将qa分支推送新tag v0.2，并将qa分支合并到master。
cd-ci拉取master分支并构建。
见图片。
