迭代实战版 Git-Flow

迭代评审

根据上线安排，需求分类：

1. 跟主迭代上线的需求（直接在 sp-dev 开发）

2. 不跟主迭代上线的需求

   • 可持续交付的需求

     1. 小需求：多个小需求合为一个 feature 分支；
     2. 大需求：单个大需求归为一个 feature 分支。

   • 跨迭代需求：拉新分支

备注：

新建的 feature 分支需要在相关的 jira 或迭代任务上标注。

迭代开发

1. feature-xxxx 分支通过 master 拉取；

   1. feature-xxxx 可含一个或多个小需求，根据分支建立时间命名；
   2. 在 jira 或迭代任务上标注对应的分支名；
   3. 大需求，以对应的模块命名，一个大需求对应一个 feature。

2. 开发完成后合并到 sp-dev 上测试环境自测；

   1. 代码提交 comment 必须清晰说明更新信息；

      • 标准：jira：8866 支付开发 - 优化回调、fix xxx、修改 xxx；

      • 禁止模糊、不明确和重复的 comment ，例如：debug、测试等。

   2. 本地测试通过后再提交，不建议零零碎碎的提交代码。

3. 自测完成后，提测，由 QA 验证；

4. 测试通过后，QA 对待发布的 feature 归类，决定哪天上线哪些 feature；

   1. QA 每天晨会同步上线安排；
   2. 确定上线的 feature 后，由 QA 指定人员新建 release 分支，合并 feature；
   3. 确定跟主迭代上线的 feature ，直接合并到 sp-dev ；
   4. 开发人员不能直接合并到 release。

5. 上预发布前，master 分支先合并到 feature 分支，避免上线冲突；

6. 从 master 拉取 release-xxxx 分支，例如：release-20180808-01；

7. 单个或多个【feature 分支】合并到 release-20180808-01，打 tag，上预发布测试；

8. 预发布 bug 直接在 release 分支修复；

9. 预发布通过后，release 分支合并到 master，使用最新的 tag 上线测试；

10. 上线通过，master 分支合并到 sp-dev；

11. 删除 release-xxxx 分支。

备注：

release 分支是唯一的，即使它有版本号，其他 feature 上线需要排队等待下一个 release。

如果存在 hotfix 上线，先验证 hotfix，再发布 release。

Bug 修复

1. hotfix-xxxx 分支通过 master 拉取；
2. 开发完成后在预发布验证；
3. 验证通过，hotfix-xxxx 合并到 master；
4. master 打 tag，上线验证；
5. 上线通过后，hotfix-xxxx 合并到 sp-dev；
6. 删除 hotfix-xxxx 分支。

命名规则

feature-xxxx：

1. 单个小需求，以 jira 编号命名，例如：feature-8888；
2. 多个小需求，以交付时间-主责人命名，例如：feature-20180808-chaoren；
3. 大需求，可按“模块-时间”命名，例如：feature-bankdeduction-20180808；
4. 大需求与 feature 一对一关系。

hotfix-xxxx：

1. 小 bug，“时间-版本”，例如：hotfix-20180808-01；
2. 大 bug，“模块-时间”，例如：hotfix-bankdeduction-20180808。

release-xxxx：

“时间+版本”，例如：release-20180808-01。