Git Commit Log的小型团队最佳实践

go4it 发布于2019-08-22 18:23 / 2124人阅读

摘要：随着团队的变大，最近在开发过程中，越来越感觉到的重要性。注意年月日，阮一峰老师写了一篇和编写指南，本文主要来源于这篇文章，只是针对我们的团队，进行了一些改造和简化，以及对一些阮老师没有提及的细小之处进行了指出。

随着团队的变大，最近在开发过程中，越来越感觉到commit log的重要性。之前的时候，团队内有人写中文log，有人写英文log；有人写的还算清晰，有人一笔更新bug就概括全貌。这些良莠不齐的commit log充斥在我们的项目中，不仅影响了查阅的效果，还会对code review产生负面的影响。因此，本文是意图从commit log的书写规范入手，并提供相应的解决方案。

注意：2016年1月6日，阮一峰老师写了一篇《Commit message 和 Change log 编写指南》，本文主要来源于这篇文章，只是针对我们的团队，进行了一些改造和简化，以及对一些阮老师没有提及的细小之处进行了指出。

1. 书写规范

经过一番调研，因为我们是小团队，需要快速迭代，容易上手，所以对阮老师提到的commit log规范进行了简化，具体如下：

1.1 type

提交 commit 的类型，包括以下几种

feat: 新功能

fix: 修复问题

docs: 修改文档

style: 修改代码格式，不影响代码逻辑

refactor: 重构代码，理论上不影响现有功能

perf: 提升性能

test: 增加修改测试用例

revert: 回退，建议直接使用Github Desktop回退，而不是使用命令

1.2 subject

用一句话清楚的描述这次提交做了什么。书写要遵循以下四种规则：

格式尽量使用谓宾，使用谓宾不通顺时，可以使用主谓，例如：

谓宾：修复xxxx
主谓：中间件支持xxxx

除了名称之外，描述尽可能使用中文，方便不同开发者理解

结尾不加句号

描述控制在20个汉字以内

1.3 body

对本地提交的详细描述，不建议。我们建议多次少量提交，而不是一次巨量的提交，有助于revert和code review，也对灾难存储有容灾。

2. 撰写工具

有工具辅助，一定比手写好，这里我们使用Commitizen这个库。
安装命令：

cd 项目目录
npm install -g commitizen
commitizen init cz-conventional-changelog --save --save-exact
// 项目做些更改之后
git add .
git cz

安装完毕之后，使用git cz来代替git commit命令即可，新的commit log提交界面会如下所示：

写完了之后的commit log如下图所示：

是不是比之前的commit log看起来清晰很多？
注意：
git bash在windows下不能通过箭头符号上下移动选择，这时候我们可以下载Cmder来作为我们的命令行工具。

2. 使用问题

1. commit log 我用20个字描述不清楚怎么办？
我们期望尽可能多次的提交，一个feature提交一次，不要出现积攒多个feature提交情况，既不有利于code review，也不有利于代码revert

2. 为什么不使用强制验证手段来限制commit log的格式？
尽管没有使用自动化验证的手段（阮老师的文章中提到了，可以自行查看），但是如果不符合书写逻辑的话，code reviewer不应该让其merge request到dev分支中。这一块我觉得天猪说的很有道理，通过人工的手段去实现这种验证，这也是为了大家养成一个良好的代码习惯。

参考文档：

《Commit message 和 Change log 编写指南》

《代码贡献规范》

服务器托管专线服务 api设计的最佳实践最佳实践 webrtc最佳实践 cdn最佳实践

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/95807.html

Git Commit Log的小型团队最佳实践

摘要：随着团队的变大，最近在开发过程中，越来越感觉到的重要性。注意年月日，阮一峰老师写了一篇和编写指南，本文主要来源于这篇文章，只是针对我们的团队，进行了一些改造和简化，以及对一些阮老师没有提及的细小之处进行了指出。随着团队的变大，最近在开发过程中，越来越感觉到commit log的重要性。之前的时候，团队内有人写中文log，有人写英文log；有人写的还算清晰，有人一笔更新bug就概括全貌...

hlcc 2019-08-02 10:28 评论0 收藏0
容器环境下的持续集成最佳实践：构建基于 Drone + GitFlow + K8s 的云原生语义化

摘要：集成测试完成后，由运维同学从发起一个到分支，此时会会运行单元测试，构建镜像，并发布到预发布环境测试人员在预发布环境下再次验证功能，团队做上线前的其他准备工作运维同学合并，将为本次发布的代码及镜像自动打上版本号并书写，同时发布到生产环境。云原生 (Cloud Native) 是伴随的容器技术发展出现的的一个词，最早出自 Pivotal 公司（即开发了 Spring 的公司）的一本技术小...

asoren 2019-06-28 17:10 评论0 收藏0
容器环境下的持续集成最佳实践：构建基于 Drone + GitFlow + K8s 的云原生语义化

摘要：集成测试完成后，由运维同学从发起一个到分支，此时会会运行单元测试，构建镜像，并发布到预发布环境测试人员在预发布环境下再次验证功能，团队做上线前的其他准备工作运维同学合并，将为本次发布的代码及镜像自动打上版本号并书写，同时发布到生产环境。云原生 (Cloud Native) 是伴随的容器技术发展出现的的一个词，最早出自 Pivotal 公司（即开发了 Spring 的公司）的一本技术小...

DevTalking 2019-07-01 17:13 评论0 收藏0
《Node.js在CLI下的工程化体系实践》成都OSC源创会分享总结

摘要：之后，在本地目录生成代码并且安装项目依赖的包，最后将本次初始化生成的所有代码自动提交到远程仓库。按照城市评选，分别评选明日之子仅限男性参加和闪亮女神仅限女性参加。背景: 随着开发团队规模不断发展壮大，在人员增加的同时也带来了协作成本的增加，业务项目越来越多，类型也各不相同。常见的类型有组件类、活动类、基于React+redux的业务项目、RN项目、Node.js项目等等。如果想要对每...

imingyu 2019-08-21 16:46 评论0 收藏0
# 前端进阶--1.为什么要制定开发规范？

摘要：使用代替可以使用工具代替结语我们应该根据公司情况业务场景和团队具体情况来制定适合自己的开发规范，开发规范不需要最好，也没有最好的开发规范，只有适合自己的。后期我将和大家分享如何制定开发规范。 0 为什么要有规范？与性能无关与功能无关与效果无关与能力无关与工期无关但是，规范必不可少与效率相关（开发、迭代和维护，重点提升维护及迭代效率）与团队相关（减少团队之间的不一致...

jasperyang 2019-08-05 17:24 评论0 收藏0