新人提交一堆不符合规范的代码？流水线提交前自动检查

摘要：

新人刚上手，对团队规范还不熟，提交里常夹带一堆不符合约定的代码，给评审和后续维护添麻烦。腾讯云 CNB 支持在提交前用 lint、commitlint、git-pr-limit 等插件自动检查，把不规范挡在早期。本文介绍如何配置。

一、新人提交不规范，麻烦出在哪

带过新人的团队，多半遇到过这种情况：新人干活积极，提交也勤，可一打开 PR，命名不规范、缩进随意、提交信息写成"update""改了点东西"、一次提交动辄改几百行……问题不大不小，却足够让评审者头疼、让后续维护吃力。

这类"不规范"不是新人态度问题，而是他们客观上还没建立起对团队约定的体感：

• 不知道具体约定：规范文档摆在眼前，条目又多，新人很难全记住，写代码时自然凭手感，写完才发现某处不达标；
• 不会把控提交粒度：新人容易把一堆改动攒成一个大提交，或者一个功能拆成十几个零碎 commit，既不利于评审，也不便于回滚；
• 评审者反复返工：基础性的规范问题占用了评审者大量精力，一遍遍打回让新人改格式、改命名，双方都累，新人信心也受挫。

靠口头提醒和文档，效果都有限——前者会忘，后者没人翻。更管用的是把规范检查前置到"提交前"，用机器在代码进入评审之前就先过一遍，不符合约定的直接拦下，让新人当场改、当场过，把不规范挡在早期。CNB 的流水线就能把这道"提交前检查"搭起来。

二、提交前检查：把规范关口往前移

腾讯云云原生构建（Cloud Native Build，简称 CNB）基于 Docker 生态，用 .cnb.yml 声明式配置流水线，支持 Pipeline/Stage/Job 三层结构，也能按分支用 glob 模式匹配、由 push、commit.add、pull_request 等事件触发。它的插件市场提供了一批规范检查插件，可以在代码提交前或 PR 阶段自动执行检查。

对"新人提交不规范"这个场景，最贴切的几类插件是：

把这些插件挂到流水线的提交前或 PR 环节，规范检查就从"评审者人肉提醒"变成"机器自动卡点"。新人提交时，不符合约定的地方会被当场指出并阻断，只能改到合规才能继续，从而在早期就把不规范挡下来。

三、代码风格：提交前用 lint 先过一遍

新人最容易踩的，是代码风格这类细节：缩进用几个空格、命名怎么起、有没有未使用的变量、有没有潜在的空值风险。这些条目碎、记不全，靠新人自觉很难稳定达标。用对应语言的 lint 插件，可以在提交前把这些问题挑出来。

CNB 插件市场按语言提供了现成的 lint 插件，例如 Go 项目用 go-lint、C/C++ 项目用 cpplint、Markdown 文档用 markdown-lint、PHP 项目用 phplint。以 Go 项目为例，在 .cnb.yml 里挂一个检查 Stage：

main:
  push:
    - stages:
        - name: 代码风格检查
          image: cnbcool/go-lint:latest
          # 让检查不通过时流水线失败（阻断提交），具体参数以插件详情页为准

逐行看：

• main: 表示对 main 分支生效，可按 glob 模式换成其他分支；
• push: 表示代码推送时触发，在提交进入仓库前就把关；
• image: cnbcool/go-lint:latest 使用官方 Go lint 插件镜像；
• 插件默认在检查不通过时让流水线失败，从而卡住这次提交（具体行为参数以插件详情页为准）。

配好之后，新人提交代码时，风格不达标会被当场拦下并给出提示。新人照着提示改到合规，提交才能通过。这样一来，规范不用再靠评审者一遍遍提醒，机器在提交前就替团队把好了关，新人也能在一次次修改中慢慢把规范内化成习惯。

实际落地时，可以按团队使用的语言，把对应的 lint 插件组合进同一条流水线，让多种语言的风格检查在一次提交里一并完成。

四、提交信息与 PR 标题：用 commitlint、git-pr-title-lint 统一格式

代码风格之外，新人还常在提交信息和 PR 标题上不规范。提交信息写成"update""修了个 bug"，PR 标题不带模块或类型前缀，会给后续的变更日志、版本管理、问题检索添麻烦。

提交信息用 commitlint 卡。约定式提交（Conventional Commits）要求提交开头用 feat、fix、docs、refactor 这类类型前缀，后面跟简短说明。配置示例：

main:
  push:
    - stages:
        - name: 提交信息检查
          image: cnbcool/commitlint:latest
          # 让检查不通过时流水线失败（阻断提交），具体参数以插件详情页为准

提交信息不符合约定（比如"update"这种），流水线直接红灯，新人只能按规范重写。提交格式统一了，团队的变更记录、版本追溯都会顺很多。

PR 标题用 git-pr-title-lint。很多团队要求 PR 标题带上模块名或类型前缀，方便检索和归类。靠人工提醒容易漏，用插件在 PR 创建时检查标题格式，不符合约定的直接拦下：

main:
  pull_request:
    - stages:
        - name: PR 标题检查
          image: cnbcool/git-pr-title-lint:latest
          # 让检查不通过时流水线失败（阻断 PR），具体参数以插件详情页为准

把这两项挂进流水线，新人提交时就会主动按规范写信息和标题——因为不按规范写，根本过不去。格式统一这件事，就此从"靠提醒"变成"靠卡点"。

五、提交粒度：用 git-pr-limit 教新人把控变更规模

新人另一个常见习惯，是一次提交改动太大或 commit 太碎。几百行的大 diff 评审者看不动、容易漏；而十几个零碎 commit 又让记录杂乱、回滚困难。用 git-pr-limit 可以在 PR 阶段检查单次 PR 的 commit 次数和代码变更行数，把变更规模控制在合理范围。

对变更量或 commit 次数超出设定阈值的 PR，插件会让流水线失败，提醒新人把改动拆分成更小的、聚焦的 PR。这对新人尤其有帮助：它不只是卡规范，更是在帮新人建立"小步提交、便于评审、便于回滚"的好习惯。

git-pr-limit 与 lint 类插件配合，能让新人的提交在"风格—格式—规模"三个层面都被规范住。新人照着流水线提示一次次调整，提交质量会稳步提升，评审者反复返工的负担也随之减轻。

六、推行建议：先提示后卡点，帮新人平稳上手

把提交前检查推给新人，方式上要讲究节奏，避免一上来就"处处卡死"打击积极性：

• 先提示、后卡点：初期可以让检查只提示、不阻断（具体是否阻断以各插件配置为准），给新人一段适应期；等团队养成习惯，再把关键项（如主干分支的风格、提交信息）改成强制卡住；
• 先卡最该卡的环节：不必一步到位。优先把团队最在意、新人又最容易犯的环节（提交信息、主干代码风格）设成卡点，其余逐步补充；
• 结合分支保护：CNB 支持对指定分支设置保护规则，做分支级别的权限管控，例如限制谁能合并、合并前需满足一定条件。把提交前检查挂到受保护分支的流水线里，就能形成"提交前检查 + 代码评审 + 卡点放行"的完整门禁，让新人代码合入更稳妥；
• 提示要清晰：流水线失败时的报错信息尽量让新人看得懂，告诉他们具体哪里不合规、怎么改，把"卡点"变成"教学"，新人改起来更快，挫败感也更少。

这样，提交前检查就不只是拦问题的关卡，也成了新人建立规范意识的抓手。

七、让机器在提交前把关，新人少返工

新人提交一堆不符合规范的代码，根源不在态度，而在于还没建立起对团队约定的体感。靠口头提醒和文档都治标，更管用的是把规范检查前置到提交前，用机器在代码进入评审之前就先过一遍，把不规范挡在早期。

CNB 的插件市场提供了 go-lint、cpplint、markdown-lint、phplint 等语言 lint 插件，以及 commitlint、git-pr-title-lint、git-pr-limit 这类检查工具，覆盖代码风格、提交信息、PR 标题和变更规模。把它们挂进 .cnb.yml 流水线，新人提交时不合规就会被当场拦下、改到合规才能继续，评审者反复返工的负担也因此减轻。

如果你的团队也有新人频繁提交不规范的代码，不妨在流水线里配上提交前检查，让机器先把好关。

想了解怎么配，可前往 腾讯云 CNB 参照官方流水线配置，在仓库 .cnb.yml 里挂上 lint、commitlint、git-pr-limit 等插件，把规范检查前置到提交前，让新人代码在进评审之前就先过一遍自动检查。