git及gitlab在项目开发中的实践应用二

之前写过实践应用一，内容比较入门，基本使用情况和大家一样，作为一个管理代码的工具。今天这篇属于高级篇，结合我们使用的情况重点介绍下git和gitlab的扩展应用。

git 钩子

我碰到个场景，需要在代码merge之前，就判断出代码或者相关的内容合不合规，而gitlab的CI事件都是后置触发。即使判断有问题，动作提交发生了，如果rd没有等到后置判断的结果，而又去处理其他事情了。当有问题的时候，再去修改。整个过程时间比较长，不如在用户提交的时候就去做些判断，经过对比调研。感觉git钩子比较适合。

git钩子安装

关于git钩子的介绍，这里简单说下，git钩子的代码是在本地的，不在代码库中。地址一般在你项目的 .git/hooks/ 里面，如下图，可以看到很多的文件，对应git不同的动作，选择一个去掉结尾的 .sample 就可以了。

场景实现

还需要考虑一点，怎么能让所有人都强制安装上，成为开发的必须一步。此时，注意到我们的项目代码使用了php composer，即：某些公共模块写成了 composer 包的形式，放在内部私有库上。部署开发环境，需要执行一步。我们也采取同样的方式，写成了一个 composer 包的形式。然后在composer的脚本中，做处理。结合我们的项目特点如下流程：

相关步骤：

一. 开发 php composer 扩展包。

二. 基于我们现实的情况，项目初次需要执行composer install/update。这样我们就把第一步的包加载引入到了项目里面。

三. 在 composer 的脚本里面加入执行语句，执行一个脚本。脚本主要实现检测 git 钩子对应的内容是否存在，文件同第一步的文件比较是否是最新的。

脚本位置可参考composer.json如下内容：

"scripts": {        
   "post-install-cmd": [            
       "@php -r \"include '项目脚本目录/check.php';脚本语句(__DIR__);\""],
   "post-update-cmd": [
       "@php -r \"include '项目脚本目录/check.php';脚本语句(__DIR__);\""],
   "post-package-install": [
      "@php -r \"include '项目脚本目录/check.php';脚本语句(__DIR__);\""],
   "post-package-update": [            
      "@php -r \"include '项目脚本目录/check.php';脚本语句(__DIR__);\""]
},

四. 如果第三部中检测到没有安装，或者不是最新的。则进行拷贝，更改文件的权限为可以执行。

执行的效果

当以上步骤都执行后，我们就可以实际使用了，当然，我这里只用到了 post-checkout（开发初期，切换分支提示去干某些事）和 commit-msg脚本 (提交代码标签检测，提交信息检测)。

1. 当需求新建立时，一般会 git branch xxx && git check xxx，然后 post-checkout 脚本就被触发了，提示你去干什么事。

    2. 代码功能完成，提交时进行一些检测。

以上，有兴趣的同学可以深入探讨。

gitlab issue

业界有很多专业的管理需求的软件，公司内部也有jira等工具，但结合友军和业务实际情况考虑。我们采用gitlab issue进行做需求跟踪。先说下背景：业务方多，平时需求对接各式各样，QQ，微信，最好的发送个邮件。业务跟踪困难。单项业务周期短，而考察了几个兄弟部门的情况和网上的介绍，整齐划一选择issue作为项目需求管理的工具。

gitlab onboard

这里不得不说 gitlab 的看板功能，这个做简单项目跟踪一目了然。业界包括很多著名的公司，都用看板功能去跟踪需求进度。我看了某些著名保险公司的团队项目管理的视频，有些团队真的准备了一块白板，然后通过贴纸条的形式，完成看板功能。然后每天开晨会的形式去跟进状态。

默认的栏目可以分成如下几种：

  Doing => To Do => Closed

当然，你也可以根据实际需要，按照你的定义分类。然后给每个issue贴上对应的标签，就可以反映出状态了，如下图是我们的线上实际情况展示。

Webhooks

我这里还有一个玩法：Webhooks，我们来看官方的介绍：

Webhooks can be used for binding events when something is happening within the project.

应用场景：怎么知道你的issue建立的对不对，格式有没有问题。当状态更新的时候能不能做些什么。代码merge request的时候，是否需要做些联动等等。以下是我们的使用情况：

gitlab CI

和业界小伙伴使用方法一样，我们这里主要体现在几个方面：

1. 提交代码之后，触发CI的规则，在里面做些检测，如：相关代码规范，单元测试等。

2. 结合jenkins做持续集成。在项目的gitlab CI对应的配置文件里面对应的规则和对接jenkins的接口，这样当你对代码做某种操作，如打符合既定特征的tag的时候，就可以触发jenkins任务了，在jenkins里可以进行构建镜像，代码上线等内容。

以上，仅是我站在个人的角度，对接触到的git和gitlab的一些总结，过程的探索了离不开大家基于自身项目的状况进行的不断尝试。如果大家有什么想了解的更细致的，请联系我。