一、分支介绍
-
Master : 主干分支, 是一个归档分支, 保留最新的一个稳定版本代码
-
PRO : Production 生产环境分支, 用于测试完毕后发布生产环境
-
FAT : Feature Acceptance Test功能验收测试环境，用于软件测试者测试使用
-
DEV : Development 开发环境分支, 用于前后端联调测试, 以及代码自测发布使用
-
Iteration : Iteration 敏捷迭代分支, 每个迭代开始时从Master检出的分支, 用于维护一个迭代周期的开发代码维护整合
-
Features : 功能特性分支, 每个迭代多个Story对应的多个分支, 以一个可独立发布的功能为单位从Iteration分支检出
Master、PRO、FAT、DEV为常驻分支, 不与迭代相关联. 且Master与PRO同为 Protected 受保护分支, 仅SM(Scrum Master)具有合并权限, FAT分支则是仅QA(测试负责人)具有合并权限, 当有新功能需要提测时, 则将Itetation分支合并到FAT并发布测试环境. 而Iteration与Features分支则为迭代相关分支, 生命周期与迭代保持一致, 在每个迭代开始的时候重新创建, 然后迭代结束后也同时删除销毁.
二、GIT分支与敏捷迭代时序图
添加图片注释，不超过 140 字（可选）
三、敏捷迭代分支管理流程图
四、GIT commit message 填写规范
现在市面上比较流行的方案是约定式提交规范（Conventional Commits），它受到了Angular提交准则的启发，并在很大程度上以其为依据。约定式提交规范是一种基于提交消息的轻量级约定。 它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与SemVer相吻合，在提交信息中描述新特性、bug 修复和破坏性变更。它的 message 格式如下:
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
1. type
type为必填项，用于指定commit的类型，约定了feat、fix两个主要type，以及docs、style、build、refactor、revert五个特殊type，其余type暂不使用。
主要type
- feat: 增加新功能
- fix: 修复bug
特殊type
- docs: 只改动了文档相关的内容
- style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
- build: 构造工具的或者外部依赖的改动，例如webpack，npm
- refactor: 代码重构时使用
- revert: 执行git revert打印的message
暂不使用type
- test: 添加测试或者修改现有测试
- perf: 提高性能的改动
- ci: 与CI（持续集成服务）有关的改动
- chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
当一次改动包括主要type与特殊type时，统一采用主要type。
2. scope
scope也为必填项，用于描述改动的范围，格式为项目名/模块名，例如： node-pc/common rrd-h5/activity，而we-sdk不需指定模块名。如果一次commit修改多个模块，建议拆分成多次commit，以便更好追踪和维护。
3. body
body填写详细描述，主要描述改动之前的情况及修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加body来作说明。
4. break changes
break changes指明是否产生了破坏性修改，涉及break changes的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等。
5. affect issues
affect issues指明是否影响了某个问题。例如我们使用jira时，我们在commit message中可以填写其影响的JIRA_ID，若要开启该功能需要先打通jira与gitlab
