代码自动化审查——repo hooks

前言

随着团队规模的增大，由于每个人的开发风格，做事方式不尽相同，给项目的维护人员带来了极大的挑战。如何保证每个人遵循一致的coding style，commit messages conventions，merge request。。。如何让每个团队成员步调一致的、风格一致的参与到项目开发中来。

项目的开发过程中一些devops技术显得越来越有必要，一些开发规范化指导文档的书写也变得越来越有必要。此篇文章主要讨论如何在我们的项目中部署coding style，commit messages自动化规范化检查工具。

部署工具

我们可以在gitlab服务器上部署工具，或者在每个客户端部署工具。

服务端部署

我们采用Gitlab进行代码托管，在Gitlab上部署服务器有如下几个选择：

• 在服务器上部署git hook
• 使用gitlab的web hooks，在另一个服务器上部署工具，通过web hooks调用
• 使用gitlab的集成功能，譬如集成Jekins，在Jekins上部署工具，这需要在一台服务器上部署Jekins

综上在服务器上部署存在两个困难：

• 需要操作服务器的权限，甚至需要额外的服务器
• 部署工作量较大，时间成本，人力成本高

客户端部署

在客户端部署我们可以采用git hooks，但是git hooks都是存储在.git/hooks路径下的，没法提交，也就没法同步个每个拉取代码的开发者。有以下几个办法：

• 每个开发者自己下载hooks，部署到自己本地的每个仓库中
• 通过第三方工具husky
• 通过repo的hooks

上面几个办法的缺点：

• 不够自动化，太繁琐，容易出错，每个开发者拉取的每个仓库都需要操作一遍，而且如果hooks更新了，还需要手动同步
• 每个开发者需要安装配置husky，过程繁琐
• 项目需要使用repo进行管理

我们选择使用repo提供的hook，因为我们的SDK目前就是使用git-repo来进行多仓库管理的。它的实现也非常简单，由维护人员在git-repo仓库中创建hooks脚本。在每个开发者执行repo sync的时候，会自动同步git-repo仓库，包括其中的hooks脚本。被repo管理的多个仓库的hooks自动连接到git-repo的hooks。每个开发者无需关注这一过程，只需享受hooks带给他们的良好体验就可以了。

目前git-repo中部署了两个hook脚本：

• pre-commit 进行coding style检查（linux kernel coding style）
• post-commit 进行commit message检查（Git Commit Message 规范）

相关脚本暂存在 repo_hooks