确定还不来看看？这样管理你的代码库既方便又省心！

又双叒叕搞事情了！

这次，建木 CI 准备通过流程化的方式对代码库中的代码进行统一管理。听了是不是有点小激动？确实，现在像这些非业务相关的东西都可以交给建木 CI 去做了，这样势必会为我们减少不少的开发工作量。闲话少说，接着就让我们一起来看看，如何搭配建木 CI 去实现这一功能吧！

在正式介绍之前，希望大家能够耐心将下面两个问题看完，这或许能让你对流程有个更好的理解！

通过何种方式管理代码库？

用建木 CI 写过流程的小伙伴应该清楚，我们在编写项目时是可以为项目添加流程触发器 webhook 的，如果对这个点不太清楚，可以点击触发器对应学习一下。为代码仓库配置了 webhook 的好处在于，今后做类似 Push、Pull Request 、新建 issue 等操作时，git 代码托管平台就会通过这个 webhook 地址向该项目发送对应请求。这样，利用这些“钩子”，在流程中我们就能非常方便地对代码库进行管理了。

哪些场景下需要触发流程对代码库进行管理？

这个问题其实没有一个确切的回答，因为什么场景下触发哪些流程取决于使用者的实际需求。这里我们以在 gitee 平台上管理代码为例，在 gitee 的 webhooks 页面中可以看到，它可以在 Push、Tag Push、Issue、Pull Request、评论这 5 个事件下对 webhook 地址发送请求。因此，我们可以利用不同的“钩子”，来实现不同情况下对代码库的管理。

看完上述两个问题后，相信大家心中的疑虑也已经少了很多。但是，这时肯定又有小伙伴心想：一共就两个问题，最后一个还没有答案，这不玩我吗？具体怎么选也没讲，无非还要自己去趟浑水过河？一整个直接无语有没有😓。哈哈哈别急，这里的浑水建木早已经替大家趟过了。如果不涉及特殊的需求，大家步调一致跟着走就行。综合实际项目的开发过程来看，其实多数情况下，我们只需涉及到如下三个场景，就可以达到管理代码库的需求。

场景一 ：push 代码到仓库主分支

1. 首先在 gitee 上创建一个名为 code-repository-manage 的仓库

1. 将该仓库交给建木 CI 管理

• 拷贝流程DSL，在建木 CI 上新建项目

• 复制项目 webhook 链接，在 gitee 仓库下进行配置

1. 流程演示

• 将新建的仓库代码克隆到本地

• 新增一个 peizhi.js 文件（文件名字可自定义），用于指定该仓库中前端代码按照何种规则进行格式化，具体格式化配置文件命名规则以及配置项可自行参考prettier进行查阅

• 新增 test.vue 文件

• 将新增的代码推送到仓库主分支，自动触发流程执行

• 查看流程的执行过程

• 流程执行成功，代码被格式化

新增了一条自动格式化的 commit 信息

查看此次提交文件的变动情况，发现 test.vue 文件被自动格式化了

场景二：同仓库的不同分支间创建 PR

• 仓库下新建其他分支 comyan

• comyan 分支下新建一个 test.js 文件

• 提交代码到 comyan 分支，comyan 分支—>master 分支创建 PR

管理代码库流程被触发

查看提交记录，test.js 已被格式化

场景三：fork 他人仓库后创建 PR

将仓库 fork 一份，在 fork 仓库下新建 PR

• 在 fork 仓库下对 test.vue 文件再次进行修改

• 新建 PR，触发流程

注意⚠️：fork 仓库下提交 PR，触发流程后只会指定 PR 审查人和更新该仓库下的最少审查人数，不会进行代码格式化。格式化操作需等到审查人将 PR 合并后，gitee 会自动把合并后的代码 push 到目标分支，从而又进入第一个场景。之所以采用这种机制，是因为流程 DSL 中没有对 fork 的仓库有 push 代码的权限。

PR 合并后流程再次被触发

test.vue 文件被格式化

这里结合前几次分享的前端代码格式化流程，给大家进行了一个知识点的串联。代码的格式化其实也属于对代码库中代码的管理，因此串连在管理代码库流程中非常有必要。同时，依赖于上面三个场景，我们还能在此基础上进行更多拓展，例如：代码 review、eslint 代码检测。

文章到这儿就结束了，如需了解流程具体实现，请参考流程DSL。

本文为建木博主「comyan」的原创投稿文章，转载请联系授权。

项⽬官⽹

项⽬托管

项⽬文档

在线体验