Workflow

Git Workflow

Commit Message |提交信息规范

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

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

我们通过git commit命令带出的vim界面填写的最终结果应该类似如上这个结构,大致分为三个部分(使用空行分割):

标题行:必填,描述主要修改类型和内容
主题内容:描述为什么修改,做了什么样的修改,以及开发的思路等等
页脚注释:放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,就好像是一份邮件。如果你只是个人的项目,或者想尝试一下这样的规范格式,那么你可以为git设置commit template,每次git commit的时候在vim中带出,时刻提醒自己。修改~/.gitconfig,添加:

[commit]
template = ~/.gitmessage

新建~/.gitmessage内容可以如下:

# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#

Merge Request

推荐团队中采用Merge Request的方式进行协作开发，即基于主分支clone之后再合并回去：

git checkout dev
git pull --rebase --prune
git checkout -b feat/x # or fix/y

# coding time

# may commit several times
git commit -m ''

# make sure rebase from origin dev branch
git fetch
git rebase origin/dev
git push # maybe `-f` flag is required if you've pushed before rebase

# create Merge Request to dev branch

# code changes according MR review

# confirm to rebase again in case others merged before your MR
git fetch
git rebase origin/dev
git push

Workflow

Git Workflow

Commit Message |提交信息规范

模板

Merge Request

Links