关于前端代码风格统一：GIT（commit/ changelog/ lint）

commit message 是开发的日常操作, 写好 log 不仅有助于他人 review, 还可以有效的输出 CHANGELOG, 对项目的管理实际至关重要, 但是实际工作中却常常被大家忽略.

本文主要梳理：
- git工作流
- git commit msg
- git changelog
- git lint / hook

常用工具：

提交信息 + changelog生成
- commitizen/cz-cli
- commitizen/cz-conventional-changelog
- conventional-changelog/standard-version
持续集成lint检验（比较狠：不按规范，代码都提交不了）
- marionebl/commitlint

git 工作流

Pull Request VS Merge Reuqest

Pull Request 要解决的问题是防止远程分支过多造成混乱，这样由每个开发人员建立自己的一个版本库，在自己的版本库建分支操作，然后往产品生产版本库发起一个 Pull 请求，同时，又要不断的跟远程的产品版本库同步保持一致，对于开源项目来说，组织松散，Pull Request 是个非常好的方式
有 master-dev 分支，比较大的功能才会新开 branch，小功能都是直接到 dev 上的，再加上团队在一起开发所以固定时间看昨日的代码，效果还不错。我们同样没有 QA，自己做的 ticket 也会找对方来做测试，但多是功能的完整性上的测试了。
每个开发人员一个 git 分支，基本上工作不会互相打扰。我们的分支策略是，对于新功能，从主干开一个功能分支，然后每个开发在功能分支上开个人分支。合并时，先 BI（Backward Integration)，，再 FI（Forward Integration)。每周四定期合并，合并时 review。之所以放在周四，是因为如果合并出错，周五还有时间修复。

Merge VS Rebase

Commit Message 格式

比较推荐是 Angular 团队的规范【1】【2】

msg格式：

<type>(<scope>): <subject>     // 标题行: 必填, 描述主要修改类型和内容
空行                         
<body>        // 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
空行 
<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 的链接

Closes #234

Revert：有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。

一个符合规范的 commit message就是一篇简短的论文，告诉别人你干了什么。

git commit 模板

手动模板修改 ~/.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
#

Commitizen工具 npm install -g commitizen cz-conventional-changelog

"script": {
...,
"commit": "git-cz",
},
"config": {
"commitizen": {
  "path": "node_modules/cz-conventional-changelog"
}
}

Change log生成

如果你的所有 Commit 都符合 Angular 格式，那么发布新版本时， Change log 就可以用脚本自动生成。 conventional-changelog 就是生成 Change log 的工具

{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"
  }
}

几个工具简介

Commitlint: 校验msg
最佳方式是Husky 结合 git hook，提前跑过各种lint后再提交

参考

优雅的提交你的 Git Commit Message ： https://zhuanlan.zhihu.com/p/34223150
使用 "5W1H" 写出高可读的 Git Commit Message ： https://zhuanlan.zhihu.com/p/26791124

Hibop / Hibop.github.io

关于前端代码风格统一：GIT（commit/ changelog/ lint） #53

常用工具：

git 工作流

Commit Message 格式

msg格式：

type: commit 的类型

scope: commit 影响的范围, 比如: route, component, utils, build...

subject: commit 的概述, 建议符合 50/72 formatting

body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting

footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接

Revert：有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。

git commit 模板

Change log生成

几个工具简介

参考

Hibop / Hibop.github.io

关于前端代码风格统一：GIT（commit/ changelog/ lint） #53

常用工具：

git 工作流

Commit Message 格式

msg格式：

type: commit 的类型

scope: commit 影响的范围, 比如: route, component, utils, build...

subject: commit 的概述, 建议符合 50/72 formatting

body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting

footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接

Revert： 有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。

git commit 模板

Change log生成

几个工具简介

参考

Revert：有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。