Git 提交信息规范化
1. 目的
-
统一团队 Git Commit 标准，便于后续代码 review、版本发布、自动化生成 change log
-
可以提供更多更有效的历史信息，方便快速预览以及配合 cherry-pick 快速合并代码
-
团队其他成员进行类{{git blame}}时可以快速明白代码用意
2. Git 版本规范
2.1 分支
master
-
主分支，用于部署生产环境的分支，无论任何时候，要确保 master 分支的稳定性
-
master 分支由 release 以及 hotfix 分支合并，任何时间都不能直接修改代码
develop
-
开发分支，始终保持最新完成以及 bug 修复后的代码
-
开发新功能时，feature 分支都是基于 develop 分支创建
feature
-
开发分支，任何时候都是从 develop 为基础，创建 feature 分支
-
分支命名：feature/开头，例如：feature/user_module, feature/cart_module
-
开发完成后，本地完成测试后，提交到 develop 合并
release
-
预上线分支，发布提测阶段，以 release 分支为基准提测
-
准备发布提测时，以 develop 为基础，创建 release 分支
-
如果测试过程中出现 bug，开发者直接基于 release 分支修改并提交
-
测试完成后，合并 release 分支到 master 和 develop 分支，此时 master 为最新稳定发布版本，用作上线
hotfix
-
线上出现紧急问题时，需要及时修复，以 master 为基础创建 hotfix 分支
-
修复完成后，hotfix 分支提测，上线前需要合并到 master 和 develop 分支，再以 master 分支上线
-
分支命名：hotfix/开头，例如：hotfix/user_module, hotfix/cart_module
2.2 常见开发流程
建立仓库关系
(master)$: git clone git@xxx_self.git # 克隆个人fork出来的代码库 (master)$: git remote add upstream git@xxx_team.git # 关联团队代码库 (master)$: git remote -v # 查看代码库关系 origin ssh://git@182.92.163.137:2222/jiangdongwei/maxwell-front.git (fetch) origin ssh://git@182.92.163.137:2222/jiangdongwei/maxwell-front.git (push) upstream ssh://git@182.92.163.137:2222/zino_tech/maxwell-front.git (fetch) upstream ssh://git@182.92.163.137:2222/zino_tech/maxwell-front.git (push)
本地代码同步
(dev)$: git fetch upstream # 更新本地项目代码库 (dev)$: git rebase upstream/develop # 更新本地托管环境 (dev)$: git checkout feature/xxx # 切换开发分支 (feature/xxx)$: git rebase develop # 更新本地feature分支 # 多人合作开发feature/xxx (feature/xxx)$: git rebase upstream/feature/xxx (feature/xxx)$: git rebase develop # 更新本地feature分支
开发新功能
(dev)$: git checkout -b feature/xxx # 创建feature分支 (feature/xxx)$: blabla # 开发 (feature/xxx)$: git add xxx (feature/xxx)$: git commit -m 'commit comment' # 场景1：独立开发feature (dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev (dev)$: git push origin develop # 把dev分支提交到fork的托管 # 发起pull request，更新项目develop分支 # 场景2：多人合作feature (feature/xxx)$: git push origin feature/xxx # 发起pull request，更新项目feature/xxx分支 # pull request 完成后，准备merge的时候，可能开始分支的时候的代码库已经过时，这个时候需要更新分支点，再更新pull request，再合并 (dev)$: git fetch upstream # 更新本地项目代码库 (dev)$: git rebase upstream/develop # 更新本地托管环境 (dev)$: git checkout feature/xxx # 切换开发分支 (feature/xxx)$: git rebase develop # 更新本地feature分支 (feature/xxx)$: git rebase upstream/feature/xxx # 更新pull request (feature/xxx)$: git push origin feature/xxx # 检查pull request更新情况，合并代码 # 删除远程分支 (feature/xxx)$: git push origin :feature/xxx
修复紧急 bug
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支 (hotfix/xxx)$: blabla # 开发 (hotfix/xxx)$: git add xxx (hotfix/xxx)$: git commit -m 'commit comment' # pull request, 提测 # 通过pull request or leader知情的情况下直接操作项目仓库 (master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master，并上线到生产环境 (dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代码
准备测试环境
(release)$: git merge dev --no-ff # 把dev分支合并到release，然后在测试环境拉取并测试
生产环境上线
Tag：采用三段式，v 版本.里程碑.序号，如{{v1.2.1}}
-
架构升级或架构重大调整，修改第 2 位
-
新功能上线或者模块大的调整，修改第 2 位
-
bug 修复上线，修改第 3 位
(master)$: git merge release --no-ff # 把release测试好的代码合并到master，运维人员操作 (master)$: git tag -a v0.1 -m '部署包版本名' # 给版本命名，打Tag
合并提交
通常本地会有很多次 commit，例如 3 次提交，然后提交到 fork 的分支之后，会有 3 次提交记录，但是代码审查和后面的合并的时候，实际上你并不希望同事看到你本地的 3 次提交记录，这个时候希望把本地先压缩之后，再上传；这个时候可以用 git rebase -i
-
在终端输入:
git rebase -i HEAD~2这里的HEAD~2表示合并最近两次的提交, 如果想合并最近三次的提交修改为:git rebase -i HEAD~3输入 git rebase -i HEAD~2 命令后, 会弹出编辑器 -
将第二行的
pick改为s“s” 为 “squash” 的缩写 -
“squash” 的意思是 将倒数的这二次提交 压缩为最后一次提交
-
然后保存
-
将
This is the commit message下面的内容改成你想提交的概述即可
具体参考：https://blog.csdn.net/ywdhzxf/article/details/90517432
https://www.cnblogs.com/amou/p/9465880.html
3. Git 提交消息规范
编写良好的 Commit messages 可以达到 3 个重要的目的：
-
加快 review 的流程
-
帮助我们编写良好的版本发布日志
-
让之后的维护者了解代码里出现特定变化和 feature 被添加的原因
Commit messages 的基本语法
当前业界应用的比较广泛的是 Angular Git Commit Guidelines
具体格式为:
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
-
type: 本次 commit 的类型，诸如 bugfix docs style 等
-
scope: 本次 commit 波及的范围
-
subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点 1. 使用祈使句，是不是很熟悉又陌生的一个词，来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点
-
body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
-
footer: 描述下与之关联的 issue 或 break change
Type 的类别说明：
-
feat: 添加新特性
-
fix: 修复 bug
-
docs: 仅仅修改了文档
-
style: 仅仅修改了空格、格式缩进、typo 等等，不改变代码逻辑
-
refactor: 代码重构，没有加新功能或者修复 bug
-
perf: 增加代码进行性能测试
-
test: 增加测试用例
-
chore: 改变构建流程、或者增加依赖库、工具等
Commit messages 格式要求
# 标题行：50个字符以内，描述主要变更内容 # # 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括: # # * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等 # * 他如何解决这个问题? 具体描述解决问题的步骤 # * 是否存在副作用、风险? # # 如果需要的化可以添加一个链接到issue地址或者其它文档
案例
feat($browser): onUrlChange event (popstate/hashchange/polling) Added new event to $browser: - forward popstate event if available - forward hashchange event if popstate not available - do polling when neither popstate nor hashchange available Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
fix($compile): couple of unit tests for IE9 Older IEs serialize html uppercased, but IE9 does not... Would be better to expect case insensitive, unfortunately jasmine does not allow to user regexps for throw expectations. Closes #392 Breaks foo.bar api, foo.baz should be used instead
参考：
本文文字及图片出自 InfoQ
你也许感兴趣的：
- 【外评】电脑从哪里获取时间？
- 【外评】为什么 Stack Overflow 正在消失？
- Android 全力押注 Rust，Linux 却在原地踏步？谷歌：用 Rust 重写固件太简单了！
- 【外评】哪些开源项目被广泛使用，但仅由少数人维护？
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗，Rust for Linux 项目内讧升级！核心维护者愤然离职：不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
- 【外评】Linux 桌面市场份额升至 4.45
- 【外评】作为全栈开发人员如何跟上 AI/ML 的发展？
你对本文的反应是：