迭代评审
需求分类：
- 小需求：多个小需求归为一个
feature分支； - 大需求：单个大需求使用独立
feature分支。
备注：
前后端配合，必须沟通好所使用的 feature；
新建的 feature 分支需要在相关的 jira 或迭代任务上标注；
SQL 语句需备注对应的 feature 分支；
缺陷修复、问题处理，也需要标注对应的分支名。
迭代开发
-
feature-xxxx分支通过master拉取；-
feature-xxxx可含一个或多个小需求； - 在 jira 或迭代任务上标注对应的分支名。
-
- 开发完成后合并到
sp-dev上测试环境自测；- 代码提交 comment 必须清晰说明更新信息；
- 标准：jira：8866 支付开发 - 优化回调、fix xxx、修改 xxx；
- 禁止模糊、不明确和重复的 comment ，例如：debug、测试等。
- 本地测试通过后再提交，不建议零零碎碎的提交代码。
- 代码提交 comment 必须清晰说明更新信息；
- 自测完成后，提测，且通过准入测试（自动化），由 QA 验证；
- 测试通过后，QA 对待发布的
feature归类，（QA）决定哪天上线哪些 feature；- QA 每天晨会同步上线安排；
- 确定上线的
feature后，由 QA 指定人员新建 release 分支，合并feature； - 开发人员不能直接合并到 release。
- 上预发布前，
master分支先合并到feature分支，避免上线冲突； - 从
master拉取release-xxxx分支，例如：release-20180808-01； -
单个或多个 <u>feature 分支</u>合并到
release-20180808-01，打releasetag，上预发布测试； - 预发布 bug 直接在
release分支修复； - 预发布通过后，
release分支合并到master，打mastertag 上线测试； - 上线通过，
master分支合并到sp-dev； - 删除
release-xxxx分支。
备注：
release 分支是唯一的，即使它有版本号，其他 feature 上线需要排队等待下一个 release。
如果存在 hotfix 上线，先验证 hotfix，合并 hotfix，再发布 release。
tag 命名：
release 分支：R20880808-01
master 分支：M20880808-01
Bug 修复
-
hotfix-xxxx分支通过master拉取； - 开发完成后在预发布验证；
- 验证通过，
hotfix-xxxx合并到master； -
master打 tag，上线验证； - 上线通过后，
hotfix-xxxx合并到sp-dev； - 删除
hotfix-xxxx分支。
命名规则
feature-xxxx：
- 单个大需求，以 “主责人-jira 编号”命名，例如：
feature-superman-8888； - 多个小需求，以“主责人-当前时间”命名，例如：
feature-superman-20180808； - 跨迭代需求，以“主责人-专项代号”命名，例如：
feature-superman-bankdeduction。
hotfix-xxxx：
- 小 bug，“主责人-时间”，例如：
hotfix-superman-20180808； - 大 bug，“主责人-模块”，例如：
hotfix-superman-bankdeduction。
release-xxxx：
- “时间+版本”，例如：
release-20180808-01。
备注：命名规则加上“主责人”，方便上线后各自清理分支。
