Cube Git flow
参考： http://www.ruanyifeng.com/blog/2012/07/git...

流程图

摘要：仓库中包含以下分支

• master release 用来发布稳定的生产版本
• develop 大版本开发
• feature-* 用于新特性的开发
• bugfix-* bugfix 用于生产环境紧急bug 的修复

主分支 master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

master 是受保护的分支，从develop bugfix- feature- 需要发起Merge Request 进行过Code review 之后才能合并到主分支。

开发分支 develop
日常开发应该在另一条分支上完成，我们把开发用的分支，叫做Develop。

develop 是受保护分支，需要发起Merge Request 进行Code review 之后才能合并

如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

开发分支的push 动作会触发Gitlab CI 编译部署。
对应公众号：魔方测试，测试网址：http://devcube.lenovo.com.cn

功能分支 feature-*
这一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，可以采用feature-*的形式命名。

创建一个功能分支：

git checkout -b feature-x develop

开发完成后，将功能分支合并到develop分支：

git checkout develop
git merge --no-ff feature-x

删除dev分支：

git branch -d feature-x
修补分支 bugfix-*
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用bugfix-*的形式。

修复分支提测，Merge Request 到 bugfix 上。

创建一个修补bug分支：

git checkout -b bugfix-jira2018 master

修补测试通过后，合并到master分支：

这一步请通过Gitlab 提交Merge Request，合并人将分支再合并到develop 之后删除分支

bugfix 是受保护分支，需要发起Merge Request 进行Code review 之后才能合并
bugfix 会触发Gitlab CI 编译部署。
对应公众号：24小时，测试网址：http://testcube.lenovo.com.cn

何时做Code Review ？
在向develop bugfix master 提交Merge Request 的时候做Code review，在存在以下问题时会拒绝合并并且给出修改意见：

代码不符合约定的规范
代码有更好的实现方式
边界条件错误
Git hook
前端eslint 代码规范检测
git commit 规范检测
在Cube 项目，写好关键字和简短描述，请勿提交无实际内容的commit msg
简化为

(): 关于git commit 规范检测，参考文档如下： - http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html - https://zhuanlan.zhihu.com/p/34223150

Commit Message 格式

目前规范使用较多的是 Angular 团队的规范, 继而衍生了 Conventional Commits specification. 很多工具也是基于此规范, 它的 message 格式如下:

(): 标题行: 必填, 描述主要修改类型和内容 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等 页脚注释: 放 Breaking Changes 或 Closed Issues type: commit 的类型 feat: 新特性 fix: 修改问题 refactor: 代码重构 docs: 文档修改 style: 代码格式修改, 注意不是 css 修改 test: 测试用例修改 chore: 其他修改, 比如构建流程, 依赖管理. scope: commit 影响的范围, 比如: route, component, utils, build... subject: commit 的概述, 建议符合 50/72 formatting body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接. 这样一个符合规范的 commit message, 就好像是一份邮件.

转:https://www.zybuluo.com/wh8766/note/1382672

本作品采用《CC 协议》，转载必须注明作者和本文链接