提高协作效率的Git Log规范与工具

2021-03-01 本文已影响0人星际码仔

前言

坊间常常流传着许多只有程序员才能看懂的经典笑话，其中就有那么一则：

《开发时间》

项目经理：如果我再给你一个人，那可以什么时候可以完工？

程序员：3个月吧！

项目经理：那给两个呢？

程序员：1个月吧！

项目经理：那100个呢？

程序员：1年吧！

项目经理：那10000个呢？

程序员：那我将永远无法完成任务。

呐呐呐，我想你已经能Get✓到笑点了。的确，不同于外界对于程序员一天到晚只会对着电脑闷头敲代码的刻板印象，实际上，与他人的沟通协作也是我们日常工作中占比较重的一部分。然而人数越多，面临的沟通的成本就越大，就越难形成统一的意见。

不知你在工作中有没有遇过这样的问题：

需要等待他人的资源到位才能开发，但是对方可能因为某些原因没有及时通知，导致开发时间被白白浪费。
更改了项目的技术实现方案，但是没有及时通知组内其他成员，导致开发中出现两套方案，造成后期维护困难。
作为领导者不能实时了解部下的代码提交情况，从而及时地进行代码审查工作，为项目上线埋下隐患。
...

如果你的日常工作中同时使用到了Gitlab、钉钉这两个工具，那么本文可以提供给你一种利用这两个工具提高协作效率的方案，不一定是最高效的方案，只能说在我的实际工作实践中是有起作用的，可以参考下。

方案预览

利用钉钉Webhook接收Gitlab仓库更新推送，提高开发效率
建立Git日志提交规范，减少沟通成本
利用AS插件标准化日志提交内容，降低入手门槛
利用Git hook校验Git日志提交格式，强制执行规范

步骤实施

1. 利用钉钉Webhook接收Gitlab仓库更新推送，提高开发效率

通常我们提交代码到Git的日志记录，是作为后期代码追溯的来源，但同时也是我们阶段性开发工作完成的标志，因此如果能在提交完成后自动通知到相关协同开发的人员，就可以避免上面所述的由于沟通不及时造成的各种问题，那么具体应该怎么操作呢？

首先，我们需要在进行协同开发的钉钉群中的群设置-智能群助手中选择添加一个Gitlab机器人，填写机器人名字后复制Webhook一栏内容。

1.png

随后，进入我们的Gitlab仓库，在Settings-Integrations中的URL一栏中粘贴我们上面复制的Webhook，并选择监听的代码分支。

2.png

如此一来，当我们往指定分支中提交推送代码时，钉钉机器人就会在群里发布谁谁提交了什么内容的消息推送，是不是很方便？

2. 建立Git日志提交规范，减少沟通成本

前面一步我们只是提高了协作开发中的及时性，但是如果提交的日志格式不规范、有效信息太少的话，仍然需要面对面沟通才能确定细节，因此下一步我们要做的就是建立Git日志提交规范，在此我们使用的是Angular规范。

Angular规范的提交日志格式如下:

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

Header

Header包括三个字段：type（必需）、scope（可选）和subject（必需）。

type

指明提交的类型，一般包含以下几种：

feat：新增功能
fix：Bug修复
docs：文档变更，如README.md等。
style：格式修改，如缩进、空格等
refactor：代码重构
test：测试用例
chore：构建过程，如增加依赖库等。

scope

说明本次提交影响的范围

subject

对提交目的的简短描述

Body

对本次提交内容的详细描述，可以分成多行，一般可包含以下内容

为什么要提交本次变更？即：目的。

本次提交是如何解决问题的？即：方法。

本次提交可能造成什么其他后果？即：影响。

Footer

备注信息，只用于两种情况：

不兼容变动

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

BREAKING CHANGE: isolate scope bindings definition has changed.

To migrate the code follow the example below:

Before:

scope: {
  myAttr: 'attribute',
}

After:

scope: {
  myAttr: '@',
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.

关闭Issue

如果当前提交针对某个issue，那么可以在Footer部分关闭这个issue 。

Closes #234

同时，还需要规定开发者的提交频率，一般建议完成一个小功能开发或解决一个Bug并完成自测后就做一次提交，这样有利于：

减少代码回退的成本。当代码审查不通过或者需求有变更时，可以最小化减少需要修改的代码范围。
执行代码审查的便利性和可控性。领导者可以专注于本次提交的内容变动，而无需阅读大量代码。

下面是一个范例：

fix(启动页登录跳转流程): 账号被踢下线弹出提示弹窗，点击“重新登录”跳转到首页了 

* 针对被踢下线情况改为跳转到登录页面
* 利用传递的isInvailToken参数判断是否是被踢下线情况

Closes #10848

如此一来，由于提交日志中提供了足够多的信息，通过阅读日志信息便可跟踪进度，完成工作对接，减少了面对面的沟通，从而使开发者可以专注于开发而避免注意力打断。

3. 利用AS插件标准化日志提交内容，降低入手门槛

当然，如果一样东西的学习和迁移成本太大，人性本能地会拒绝执行。因此要寻求自动化的方案来帮我们降低入手门槛，在此我推荐一个AS插件————Git Commit Message Helper，此插件可以以填写表单的方式，帮我们标准化日志提交内容。

3.png

如图所示，此插件会在提交代码的窗口新增一个快捷按钮，点击之后就会弹出表单让我们填写，我们按照表单上面的指引填写之后，就会自动帮我们生成符合规范的提交日志。

4. 利用Git hook校验Git日志提交格式，强制执行规范

而当团队需要强制执行制定的规范时，则可考虑在开发者提交日志时就先执行日志格式的校验，从而从源头上抑制不合规范的日志的产生。在此我们利用的是Git的hook机制，通过使用正则表达式校验日志内容，不合规范而不予通过。

首先我们在项目的.git/hooks目录下找到commit-msg.sample文件，并改为 commit-msg，即去掉后缀，将里面的内容修改为：

#!/bin/bash
MSG=`awk '{printf("%s",$0)}' $1`
if [[ $MSG =~ ^(feat|fix|test|refactor|docs|style|chroe)\(.*\):.*$ ]]
then
    echo -e "\033[32m commit success! \033[0m"
else
    echo -e "\033[31m Error: the commit message is irregular \033[m"
    echo -e "\033[31m Error: type must be one of [feat,fix,docs,style,refactor,test,chore] \033[m"
    echo -e "\033[31m eg: feat(user): add the user login \033[m"
    exit 1
fi

如此一来，当我们提交不合规范的日志时，提交就会失败，并输出提示信息。

总结

《应用架构指南》一文中说，“不要一次又一次地编写相同的样板代码，这是在做无用功。相反，您应将时间和精力集中放在能让应用与众不同的方面上，并让 Android 架构组件以及建议的其他库处理重复的样板”。

同样道理，我们也不要把有限的时间精力浪费在一些低效的沟通上，而应该专注于本职的开发工作，巧妙利用一些现有的自动化的工具帮我们完成大部分的工作。