在Git上如何强推代码规范

引言

最近参加了“前端规范制定topic”小组，小组成员一起制定了html、css、js、es6、vue和react等规范，但规范制定好了怎么进行推广去强制执行呢，已知我们的项目都是用git做管理的，所以马上想到在git上做文章，本文讲述的就是如何在git上推行代码强校验。

git知识点

说到git，我们先来了解下平时项目中不是很关注的几个git概念.

git仓库

git是分布式版本管理系统，可以有多个代码仓库，所有参与项目的开发者都可以拥有自己的本地仓库，每一个本地仓库都是一个完整的版本库，即使不联网，也可以任意的进行开发、创建分支、commit和查看版本的历史提交记录等。

但每个人都在自己的本地仓库开发，怎么做到代码共享和同步呢？在我们的项目中，通常都会建立一个大家都可以访问的共享仓库，这个共享仓库放在一个专门的线上服务器上，我们也叫它远程仓库。远程仓库和本地仓库的唯一差别就在于它是裸仓库，就是不包含任何工作目录，仅仅是由 “.git” 目录组成的。它作为服务器仓库供各开发者push、pull数据，实现数据共享和同步，不保存文件，只保存历史提交的版本信息等。

git存储方式

说完git仓库，我们来了解下git的存储方式。git存储数据更像是把数据看作是对小型文件系统的一组快照，每次提交更新或者是保存项目状态时，它主要对现有的文件制作一个快照并保存这个快照的索引。这个“快照”就是git对象，而“快照的索引”就是对象名。所有用来表示项目历史信息的文件,都是通过一个40字符的（40-digit）“对象名”来索引的。对象名看起来像这样的：26e5847434caa7597c4088de8ecab9cd567957d1。

在git里，每一个“对象名”都是对“对象”内容做 SHA-1哈希计算得来的， SHA-1是一种密码学的hash算法，这样在每个仓库中不同内容的对象就会有不同的对象名。git有四种类型的对象："blob"、"tree"、 "commit" 和”tag”：

“blob”用来存储文件数据，没有文件名，只有内容
“tree”有一串指向blob对象或是其它tree对象的指针，它一般用来表示内容之间的目录层次关系
“commit” 指向一个"tree对象", 并且带有相关的描述信息，如提交者、提交时间、注释等等
“tag”用来标记某一个提交(commit) 的方法

所以下面所描述的获取文件信息基本上都是通过各种git命令操作hash对象名来获取的，这也是为什么在这里介绍“git存储方式”的原因，方便大家更深刻的了解git命令。

作用域

由git仓库的定义可以看出，本地仓库因为是本地的，任何能接触得到仓库的人都可以进行修改、删除等，所以本地仓库不适合做代码强校验。那只能考虑远程仓库了，可以当用户push推送的时候，校验代码，如果不符合规范，就拒绝这次提交，虽然你不能阻止开发者写出糟糕的代码，但可以防止这些代码流入官方的代码库。

git钩子

好了，确定了规范在服务端仓库上来强推行，但怎么做到当用户push动作触发的时候去做一下代码强校验呢，经过调研发现，git钩子正好解决了我们的这个问题。

什么是git钩子呢？git钩子是在git仓库中特定重要动作发生时自动运行的脚本，它可以让你自定义git内部的行为，在开发周期中的关键点触发自定义的行为。这样来说，git钩子就可以帮我们来推行规范了。

git钩子到底什么样呢，它存在于每个git仓库的.git/hooks目录中，当你观察.git/hooks时，你会看到下面这样的文件：

hooks目录下展示的钩子并不全，这里带simple后缀的只是git的大部分钩子，.sample拓展名防止它们默认被执行，想要运行一个钩子，去掉后缀名或者在git官网查看相应钩子名称添加新文件即可。

钩子分类

按照钩子的定义，hooks下的钩子可分为本地钩子和服务端钩子两类。本地钩子基本由提交和合并这样的操作所调用，而服务器端钩子主要用于接收推送这样的联网操作。上面“作用域”部分已经提到，我们只能在服务端仓库做代码强校验，所以接下来主要研究服务端钩子。
钩子语言

这些钩子就是git内置的一些脚本，内置的脚本大多是shell和perl语言的，但你可以使用任何脚本语言，只要它们最后能编译到可执行文件。本人对python比较熟，所以整个的开发用的是python语言。

git服务端钩子

由上面的git知识点一步步看下来，我们就可以确定了代码校验合适的地方是在服务端钩子上，但服务端钩子也有好多，我们的代码规范要在哪个钩子做比较合适呢，接来下就具体介绍下服务端最有用的3个钩子，并找出一个适合我们的钩子。

pre-receive

这个脚本在git push向远程仓库推送操作时，最先被调用。它没有参数，但是可以从标准输入获取一系列的推送引用。如果它以非零值退出，所有的推送内容都不会被接受，所以这是强制推行开发规范的好地方。

#!/usr/bin/python

# -*- coding: utf-8 -*-

import re,fileinput

for file_line in fileinput.input():

    #从标准输入可以获取三个值

    #推送前的引用指向的内容的SHA-1值，用户准备推送的内容的SHA-1值，引用的名字（分支）

    old_hash,new_hash,branch = re.split(r'\s+', file_line.strip('\n'))

# 放弃推送

# sys.exit(1)

update

update脚本和pre-receive脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。假如推送者同时向多个分支推送内容，pre-receive只运行一次，相比之下update则会为每一个被推送的分支各运行一次。它不会从标准输入读取内容，而是会接受三个参数，这三个参数信息和pre-receive在标准输入读取信息相同。如果update脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。

#!/usr/bin/python

# -*- coding: utf-8 -*-

import sys

#接受三个参数

#引用的名字（分支）, 推送前的引用指向的内容的SHA-1值，用户准备推送的内容的SHA-1值

branch,old_hash,new_hash = sys.argv

# 只放弃当前分支的推送

# sys.exit(1)

post-receive

post-receive脚本在成功推送后被调用，可以用来更新其他系统服务或者通知用户，它接受与 pre-receive相同的标准输入数据。它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器，或者更新问题追踪系统（ticket-tracking system）等。

服务端推送成功后调用的钩子不止post-receive这一个，如上面.git/hooks图中的post-update也是其中之一，但是为什么不介绍post-update呢？原因是它的输入获取值太单一，post-receive更像是post-update的超级集合，所以推送成功后的调用我们一般用post-receive。

我们经常用到的gitlab中的web hook就绑定了这个钩子，当然web hook是绑定了好几个不同的钩子的，post-receive只是其中一个，如下图的web hook的中的Push events事件触发的就是.git/hooks中的post-receive脚本

分析这三个钩子，我们显然选push成功前调用的钩子，那到底是选pre-receive还是update呢？考虑到我们的项目很少有一次push多个分支的场景，最终选了pre-receive钩子来做我们的代码强校验。

在pre-receive钩子里做代码校验

钩子选择好了，接下来就是怎么做了，下面是一个简单的流程图，具体为从标准输入中获取三个值，分别是推送前的引用指向内容的SHA-1值，用户准备推送内容的SHA-1值和分支名，我再代码里分别用变量old_hash,new_hash和branch来表示这三个值，下面有用到。根据这三个值用git命令分别获取用户信息和提交的增量文件，把这些文件推送到eslint服务上进行代码校验，校验成功就直接push通过；不成功则在客户端返回校验结果，push不通过。

根据上面的描述，重点介绍下怎么获取用户信息和增量文件

用户信息

获取用户信息的目的是传给eslint服务端，在服务端可以给分析用户的行为及给用户发送邮件等这个命令可以定制化格式只获取用户的信息

%cn: committer name
%ce: committer email
%ct: committer date, UNIX timestamp
--no-patch: 不显示提交差异

'git show --format="%%cn %%ce %%ct" --no-patch %s' % new_hash

定制化后运行的结果是下面这样的，可以获取提交者的信息：

增量文件

增量文件取得是本次推送引用指向内容的SHA-1值和推送前的引用指向内容的SHA-1值中间的差值。命令如下，其中 --name-status是只取差异文件的名字和状态值

为什么不直接取本次推送引用指向内容的SHA-1值而取差值呢，原因是上次推送和本次推送中间可能隔了好几个commit，每一个commit对象都会生成一个唯一的SHA-1哈希字串的。

'git diff --name-status %s %s' %(old_hash,new_hash)

运行后得到的结果是：

后面的就是怎么获取文件及和eslint服务通讯的问题了，在这里不是重点就略过了...

总结

本文可以说是我接到任务后，从只了解git的git pull、git clone、git push等几个常用命令到怎么在git上实现我们的需求的一个探索过程，希望里面的介绍对不是很熟悉git的同学有点帮助，另外也简单介绍了下我们强推规范的大致流程。后续会继续研究下gitlab和git钩子的关联关系。