如何在内部 Stash 服务器上添加 hook

关于 hook

所谓的 hook 就是存在于.git/hooks/ 目录下的一些脚本文件（shell、Python、Ruby、Perl 皆可），这些脚本文件能够在某些 git 操做执行以前或者以后触发，可让开发者来自定义属于本身的工做流。好比咱们能够在本身本地添加一个 hook 在咱们每次提交 commit 信息之后执行，检查咱们的 commit 信息是否符合规范，若是不规范就退出当前此次提交。git 为咱们预留了 14 个 hook 分别适用于本地 commit 、邮件通知、衍合、合并、开新分支以及服务器接收提交。在使用的时候只要把咱们写好的脚本按照 git 要求的文件名放到 git 仓库中的 .git/hooks/目录中就好。

如何在 Stash 中添加 hook

若是想添加服务器 hook，就须要在服务器端的 .git/hooks/目录下添加脚本文件，这就须要拥有 Stash 服务器的文件系统的权限，若是是在公司的环境下还要去向管理员申请权限，是比较麻烦的，还好目前 Stash 上有一些插件能够比较方便的实现咱们通常在服务器添加 hook 要实现的需求，这里挑两个简单介绍下。

Yet Another Commit Checker

这个插件主要用于检查 commit message ，其是一个 pre-receive hook ，就是说若是 commit message 若是不合法，这些 commit 就会没法 push 上去。该插件的主要功能有：

• 检查 commit 的邮箱、姓名；

• 利用正则表达式检查 commit message；

• 经过 JIRA 检查 commit message 中的 task ID 是否合法，同时会忽略一些相似 task ID 的字段（好比『UTF-8』这种的）；

• 经过 JQL规定查找到的 task 的状态，好比能够规定 task ID 对应的 task 必须状态是 Open 的；

• 经过正则检查分支名；

• 自定义错误提示消息；（默认的错误消息里头有一只萌萌的小熊）

• 忽略 merge 的 commit 不进行检查，也能够经过正则忽略一些 commit 不进行检查， 也能够忽略从其余 service 来的 commit （如 CI 系统的生成的 commit）。

使用配置

在 Stash 中安装插件后，点击插件后就能够打开插件的配置项。配置项分为不少部分，如下一一陈述。

首先是配置 commit message 的检查选项，前两项开启后会检查 push 的 commit message 中是否使用的是 Stash 上的用户名和邮箱。第三项则是自定义的用于检查 commit message 的正则表达式,这里要求整个 commit message 都要符合这个正则表达式。这里写的是([A-Z]+-\d+)-(.|\n)*，最后的(.|\n)*是为了识别多行的 commit message。

而后是配置是否检查 task ID 合法。前面的正则表达式仅仅可以检查格式上是否符合一个 task ID 的格式，可是会把『IPH-456-test』这样的内容认为是合法的，要想作进一步的检查，就须要向 JIRA 查询这个 task ID 是不是合法的。

开启了第一个选项之后，若是以前的正则表达式的部分没有分组，那么就会用全部的 commit message 做为 task ID 去进行合法性校验（首先 commit message 要符合正则）。若是正则表达式有分组，就会用符合正则表达式的部分中对应分组的部分做为 task ID 去进行合法性校验。能够用第二种方式来主动定位 task ID。（若是有多个分组呢？测试后发现有多个分组时会把第一个分组做为 task ID）。

第二个选项则是会忽略一些形似 task ID 的、符合正则的 commit message 部分，好比『UTF-8』这样的部分。开启了第二个选项能够防止由于这样的字符存在而致使的检查失败。

第三个选项是使用 JQL 来设置查找到的 task 的状态，好比能够经过 status="open"来指定对应的 task 必须是处于 open 状态的。更多的一些用法能够参照 JQL 的语法。

而后还能够利用正则表达式检查分支名。

自定义错误信息，这样 push 失败之后就会这样显示（小熊是默认的 header）：

最后就是设置例外 commit 了，第一个选项开启后能够提交 merge commit ，第二个就是用正则来进行例外设置，第三个开启后则是会例外一些来自服务的 commit。