安装方式
- mac 下，brew install git-flow-avh(该模型比较好，具有 bugfix 分支)
使用方式
- 前期工作：需要在 wiki 上建立相关发布日志，记录每次版本
- changelog（该记录一般为产品或项目在迭代周期开始之前指定之需求）
- git flow init(初始化)
场景 1
产品迭代周期的开始——产品经理提出了一堆新功能（可以说一个功能【jira】对应一个 feature 分支），新建 feature 分支到完成发布的生命周期如下
1.git flow feature start 180827-radar109（新建分支 feature/180827-radar109 并切换）
2.git flow feature publish 180827-radar109 (将该版本推到远程仓库，便于小伙伴获取)
3.git flow feature finish 180827-radar109（完成该功能分支，并删除。同时切回 develop 分支）
4.发布测试平台交由提测，假设测试通过，直接跳到 7。测试不通过有 bug，跳到 5。
5.git flow bugfix start 180827-radar109(新建分支 bugfix/180827-radar109 并切换，也许测试提出了新的 jira 来修改，这里不一定是 109)
6.与 2-3 步骤类似
7.每天中午自己的分支拉一遍 develop 分支（防止自己的 feature/bugfix 分支不是最新）
8.产品经理提出的所有新功能，小伙伴全部完成之后。跟产品经理确认这个周期不再有新的功能，同时他在灰度测试平台确认可以发布线上，该周期基本结束。
9.git flow release start 产品版本（从 develop 分支新建 release/产品版本）
10.git flow release publish 产品版本（发布到远程仓库，便于大家进行小修小改，无需进行 bugfix 分支，这是因为之前 4 步骤针对每个 feature 已经提测，这里理论上只是小修改如文案不到位之类）
11.release 版本发布正式平台，一天时间缓冲进行 UAT 测试，若无问题第二天进行第 11 步骤，若有问题直接针对该 release 分支修改
12.git flow release finish 产品版本（完成 release 分支，并合并到 develop 和 master 分支，同时使用该版本名字打 tag）
13.在 wiki 某角落，写下该周期之发布记录。同时使用 release 脚本运行记录。
14.发布平台使用 master 分支，发布所有线上机器。
场景 2
产品经理或者客户提出线上有 bug，需要立刻修改的作法如下
需要注意，hotfix 大多是紧急情况，测试人员有可能不到位，这里更多依赖自测，然后直接发布 master
1.git flow hotfix start 版本名字-专有名字（可能有多个 hotfix 给多个小伙伴修改，这里会从 master 切出分支 hotfix/版本名字-专有名字）
2.git flow hotfix publish 版本名字-专有名字（push 到远程仓库，万一小伙伴突然有事或者电脑挂了，其他小伙伴可以接力改）
3.git flow hotfix finish 版本名字-专有名字（合并到 master 分支，并对 hotfix 版本打 tag，然后删除）
4.发布平台使用 master 分支，发布所有线上机器。
场景 3
项目经理和客户确认可能只有两个里程碑节点，这时候迭代周期如何确定
1.内部和项目经理制定更为详细的周期节点，或使用石墨管理，或使用 wiki 管理（工具只是手段）每个周期内更细致的需求，多个周期节点的制定有利于发布线上，给项目整体以信心
2.如果两个里程碑节点发布线上（线上只会存活两次正式版本），大家认为已经足够，则无须讨论
3.具体情况具体分析，重要的是人而不是死板的步骤
场景 4
产品在迭代周期中间变更部分需求
1.视需求变更的复杂度而定，如果影响到周期结束时间，可以和产品经理商量修改结束时间，如果时间不能更改，则寻求更多的资源（研发，加班）
2.频繁变更需求则应拒绝，请产品思考清楚