Git 开发流程

R先生专栏
258 阅读8分钟 
本文已参与「新人创作礼」活动，一起开启掘金创作之路。

开发流程

当你想要对代码进行修改时，请严格按照以下步骤进行

  1. 拉取最新的develop分支到本地
  2. 基于最新的develop分支新建你自己的本地分支
  3. 修改代码后，进行commit和push
  4. 切换到develop分支并拉取最新的develop分支到本地
  5. 切换回你自己的本地分支，然后执行命令git rebase develop将你的分支变基到最新的develop分支
  6. 执行git push -f强制推送你变基后的分支
  7. 在 Gitlab 上新建 Merge Request

Commit 规范

Commit 规范

Commit 规范采用常用的 Angular 团队所使用的规范，具体如下：

<type><scope>: <subject>
<空行>
<body>
<空行>
<footer>

type 规则（必填）

type 代表本次 commit 的类型，有且仅有如下几种：

  • feat - 功能性更新
  • fix - bug 修复
  • style - 改变代码格式（如删除空行、格式化代码、去除不必要的分号等等）
  • refactor - 既不是功能更新也不是 bug 修复的更改（建议对代码进行重构的时候使用）
  • perf - 代码改变提高了性能
  • test - 添加测试用例或者修改测试用例
  • build - 由打包工具造成的改变（如gulp、webpack编译文件）
  • chore - 既不是源码的修改，也不是测试用例的修改（修改项目相关配置时可以使用）
  • revert - 撤销之前的提交

scope 规则（必填）

scope 代表本次 commit 的影响范围，暂定规则如下：

  • 本次 commit 修改的组件
  • 本次 commit 修改的文件
  • 本次 commit 修改的文件夹

注意：

  • 选取时从上往下匹配
  • 组件名称应使用大写字母开头，多个单词每个单词都以大写开头
  • 文件名应包含完整后缀，如index.js、.eslintrc.json

subject 规则（必填）

用一句简短的话描述本次修改的内容，不要超过30个汉字，以动词开头

建议选用如下动词：

  • 新增（组件、属性、事件、API）
  • 删除
  • 修正
  • 修复
  • 修改

正确示例：

  • 新增 Collapse 组件
  • 新增 top 功能
  • 删除 color 属性
  • 修复 direction 属性不生效的问题
  • 修正 column 属性拼写

注意：

  • subject 应该仔细斟酌，fix 和 feat 类型的 commit 的 subject 将会出现在更新日志中，

所以书写时应考虑这句话出现在更新日志中是否合适

  • subject 中不要包含组件名或者文件名，因为 scope 中已有对应名称

body 规则（选填）

如果 subject 无法对本次 commit 进行清楚的阐释，则在 body 中进行补充说明。

建议填写以下内容：

  • 为什么进行本次修改
  • 本次修改了哪些内容
  • 修改后的影响有哪些

body 需要注意换行问题，不要写在一行不换行，建议在50个字以内进行断句换行。

footer 规则（选填）

footer 中只填写两种内容：

  1. 这次 commit 和某个 issue 相关联，提交后能关闭该 issue，则填写：

    close #748

    或者

    fix #745

  2. 这次 commit 有不兼容上个版本的代码，则以BREAKING CHANGE: 开头填写不兼容信息，如下：

    BREAKING CHANGE: Message组件top属性单位由px改为rpx

Commit 示例

一个完整规范且正确的 Commit 示例如下：

fix(NoticeBar)：修改top属性单位为rpx

NoticeBar组件的top属性单位之前为px，会出现无法自适应的问题。
更改为rpx后可对屏幕进行自适应。

BREAKING CHANGE: Notice-Bar组件top属性单位由px改为rpx

Close #745

推荐 commit 规范信息生成插件

错误示例

  1. subject描述中出现组件名称

    feat(Button): Button 组件新增 size 属性

    因type（括号中的内容）已经指定了组件，所以 subject 描述信息中无需再指明组件

  2. 单词未添加空格

    feat(Button): 新增size属性

    为了生成的 changelog 的可读性，所有的单词左右都需要添加一个空格

  3. feat、fix 类型需要慎重使用

    feat(Card): 更新 validator 校验器校验规则

    因为 feat 和 fix 类型的 commit 信息会出现在 changelog 中，所以要保证这条信息是面向用户的。如上例所示，因为 validator 仅是我们自己内部使用，并不面向用户，所以用户并不关心这个校验器的新增功能。建议使用 chore 代替此处的 feat（chore 的意思是琐碎的事务）

其他事项

一个 commit 应该是一个有意义的 commit

有意义的定义如下：

  • 新增了一个功能或组件
  • 修复了一个bug
  • 解决了一个issue
  • 重构了某个组件或文件
  • 改善了现有代码的构建流程或风格

无意义的定义如下：

  • 临时工作进度保存
  • 误提交的 commit
  • commit 信息不规范或缺失
  • subject 无法准确描述此次 commit

注意：一个 commit 的提交应该保证代码的可运行性和完整性。

  • 可运行性：commit 提交后，运行代码不能报错
  • 完整性：commit 提交后，当前代码中不能包含缺失的功能（如某个功能做了一半就提交）

Merge Request 规范

概述

merge request（以下用pr代称） 需要严格遵循以下原则**：

  • 一个 pr 只围绕一件事
  • 避免过大的 pr

一个 pr 只围绕一件事

一个 pr 应该只负责一件事，这遵循设计模式中的单一职责原则

如何定义一件事：

  • 处理了一个 issue
  • 解决了一个bug
  • 新增了一个组件或功能
  • 重构代码实现了某一个目的

一个 pr 可以包含多个 commit，但要注意尺度，保证 pr 不要过大

避免过大的 pr

该条规则对于新增组件的 pr 例外

一个 pr 的文件改变最好少于12个文件（排除build产生的文件）

信息填写

Title

Pr 仅包含一个 commit

直接使用 Github 默认填写的信息，即 Title 为 commit msg 的 subject 部分，Content 为 commit msg 的 body 部分

Pr 包含多个 commit

描述清楚这个 Pr 所做的事情，格式：[名词]+动词+名词+[形容词]+[名词]

例如：

  • 修复 Collapse 组件无法展开的问题
  • Collapse 组件添加 top 属性
  • 新增 Message 组件
  • 删除 Message 组件 color 属性
  • 修改 Message 组件 top 属性单位为 rpx

注意英文单词左右添加一个空格方便阅读

动词建议从下列选项中选取：

  • 新增（组件、属性、API）
  • 修改
  • 修正
  • 删除

Content

如果 title 已经描述清楚了此次 pr 的目的，则 Content 可以留空，否则应该对此次 pr 进行详细的描述

其他规则

连接 issue

如果这个 pr 解决了某个 issue 提出的 bug 或者 feature，则应在 pr 中将此 issue 关联起来

在 pr 描述中 使用如下关键字可将 issue 关联起来：

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

示例： close #756

然后在下图中设置关联issue：

关联 issue 的好处：

  • 可以在 issue 界面快速跳转到这个 pr，查看修复的情况
  • 在该 pr 被合并进 master 分支后，对应 issue 会被自动 close。所以连接了 pr 的 issue 不需要手动 close

分支命名规范

在新建分支时，务必遵循以下规范：

<type>/<scope>/<issue>

type

type 对应 commit 信息中的 type，（参考 commit 规范中的 type 规范）

scope

scope 对应 commit 信息中的 scope，（参考 commit 规范中的 scope 规范）

issue

issue 是对该分支要修复问题的描述或者issue的编号

示例

下面是一些分支名称的示例：

  • fix/notice-bar/768

    含义：修复 notice-bar 组件的 issue 编号 768 的问题

  • feat/collapse/color

    含义：collpase 组件新增属性 color

版本发布流程

1.issue标签的使用

  • Component:[name] 用于特定组件相关的issue
  • bug 确认是bug的问题
  • feature 未来需要考虑支持的功能

2 修复bug

  • 必须从develop分支拉取修复分支，命名方式为：hotfix/[命名]
  • 如果有删除文件，确保 dist 和 example/dist文件删除干净
  • 提交pr之前，必须执行 git rebase develop 命令，保证与develop分支的同步，如果代码有冲突，解决完冲突后再提交并提PR

发布流程

1 编辑更新日志以及升级版本号

  • 如果发布的是带有新功能的版本，需先把feature分支手工合到develop分支。
  • 从 develop分支新建一个release分支用来做发布的修改（版本号）
  • 在lin docs中添加发布日志
  • push release 分支并发起 PR 请其他同学 review
  • develop 分支发起 PR 到 master（ 不可以使用 splash merge！ ）
  • 稳定版本后需要标记 TAG 和 关联 release 版本

2 发布

  • 按照语义化版本修改版本号，bugfix 升级小版本 ，新功能添加升级中间的版本号

  • END -

avatar
文章
阅读
粉丝