git工作流-基于联想cube项目实践

Cube Git flow

参考: http://www.ruanyifeng.com/blog/2012/07/git.html

流程图

摘要:仓库中包含以下分支 
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-*的形式命名。

  1. # 创建一个功能分支:
  2. git checkout -b feature-x develop
  3. # 开发完成后,将功能分支合并到develop分支:
  4. git checkout develop
  5. git merge --no-ff feature-x
  6. # 删除dev分支:
  7. git branch -d feature-x

修补分支 bugfix-*

最后一种是修补bug分支。软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

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

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

  1. # 创建一个修补bug分支:
  2. git checkout -b bugfix-jira2018 master
  3. # 修补测试通过后,合并到master分支:
  4. # 这一步请通过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 
简化为

  1. <type>(<scope>): <subject>

关于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 格式如下:

  1. <type>(<scope>): <subject>
  2. <BLANK LINE>
  3. <body>
  4. <BLANK LINE>
  5. <footer>
  • 标题行: 必填, 描述主要修改类型和内容
  • 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
  • 页脚注释: 放 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

tags: Git,项目管理,gitflow