Hibop
关于前端代码风格统一：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 格式
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
