移动端git管理规范

一、GitFlow

Git的分支管理规范我们参考GitFlow， GitFlow是由荷兰程序员Vincent Driessen提出的Git管理规范（A successful Git branching model）。

二、GitFlow 常用分支

master

• 主分支 , 产品的功能全部实现后 , 最终在 master 分支对外发布
• 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改
• 所有在 master 分支的推送应该打标签做记录,方便追溯
• 例如 release 合并到 master , 或 hotfix 合并到 master

develop

• 主开发分支 , 基于 master 分支克隆
• 该分支为只读唯一分支 , 只能从其他分支合并
• feature 功能分支完成 , 合并到 develop
• 从 develop 创建 release 分支提测
• release/hotfix 分支上线完毕 , 合并到 develop 并推送

feature

• 功能开发分支 , 基于 develop 分支克隆 , 主要用于新需求新功能的开发，属于临时分支
• feature 分支可同时存在多个 , 用于团队中多个功能同时开发
• 功能开发完毕并测试完成后合到 develop 分支。合并后此分支删除(谁合并谁删除)

release

• 从 develop 分支克隆，属于临时分支
• 用于提交给测试人员进行功能测试 , 测试过程中发现的 BUG 在本分支进行修复 , 修复完成上线后合并
• 合并到 develop/master 分支并推送(完成功能) , 打 Tag
• 合并完成后此分支删除(谁合并谁删除)

hotfix

• Bugfix 补丁分支 , 基于 master 分支克隆 , 主要用于对线上的版本进行 BUG 修复，属于临时分支
• 修复完毕后合并到 master 分支并推送 , 打 Tag
【注意】如不对 bug 进行临时发版，不需要合并到 master 分支
• 合并到 develop 分支并推送
• 合并到 develop/master 后，此分支删除(谁合并谁删除)

三、主要工作流程

GitFlow 的工作主要工作流程如下

image.png

四、code review

code review 有条件的，可以采用Gerrit 、phabricator 等三方工具，他们会有一个中心仓库，方便code review，没条件的可以用gitlab自带的Merger request，在合并至develop时进行 code review

Commit Message规范

目前 AngularJS 在github上的提交规范是被业内很多人认可的，也被大家逐渐引用。同时针对这种提交格式也有成熟的工具，来根据commit的message记录自动生成Change Log内容。所以我们也采用同样的规范来进行约束。

AngularJS Git Commit Message规范 - Google Doc文档需翻墙。

格式：Commit Message包括三部分内容： header，body和footer。其中header是必须的，body和footer可以省略。

():

header: header部分只有一行，包括三个字段type（必需）、scope（可选）和subject（必需）。

    *   type：用于说明commit的类别。
        *   feat: 新功能(feature)
        *   fix：修复bug
        *   update: 普通的内容修改
        *   docs：文档
        *   style：格式(不影响代码运行的变动)
        *   refactor：重构(即不是新增功能，也不是修改bug的代码变动)
        *   test：增加测试
        *   chore：构建过程或辅助工具
        *   scope：用于说明commit影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
        *   subject：commit目的的简短描述。

# 新功能
feat: 轻应用离线包管理
# 修复bug
fix: 修复下载的xmind类型文件，预览识别类型不正确的问题
# 文档更新
docs: 轻应用离线功能的文档更新
# 重构
refactor: 优化下载预览
# 增加测试
test``: 下载逻辑增加单元测试
# 自动化、脚本等
chore: 修改sonar扫描的配置信息
 ```

body：对本次commit的详细描述，可以分成多行。

More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so.
Further paragraphs come after blank lines.

    - Bullet points are okay, too
    - Use a hanging indent

footer：只用于以下两种情况
- 如果当前代码与上一个版本不兼容，则footer部分以BREAKING CHANGE开头，后面是对变动的描述，以及变动理由和迁移方法。
  BREAKING CHANGE: isolate scope bindings definition has changed.
  To migrate the code follow the example below:
```
Before:
scope: {
         myAttr: attribute,
}
After:
scope: {
myAttr: @,
}
```
关闭Issue，如果当前commit是针对某个issue，那么可以在footer部分关闭这个issue。
```
 Closes #234 #445 #8888
```