ubuntu gitlab代码审查规范

Ubuntu GitLab 代码审查规范

一 规范目标与角色职责

• 目标：保障代码有效、可理解、可维护、安全，在Ubuntu环境下以**GitLab Merge Request（MR）**为核心开展高效协作。
• 角色与职责：
  • 作者 Author：尽早发起评审；按模板提供上下文；响应评论并迭代；仅在变更小且简单时可跳过单独评审直接找维护者；涉及安全时主动 @Application Security Team（@gitlab-com/gl-security/appsec）。
  • 评审者 Reviewer：从正确性、逻辑、边界、可维护性、性能与安全多维度给出具体可执行意见；按领域（如backend、database）分工评审；使用侧边栏指派与“Approve additionally”完成批准。
  • 领域专家 Domain Expert：对特定技术/功能/代码域具备深度经验，按CODEOWNERS规则先行或并行评审。
  • 维护者 Maintainer：依据审批规则合并；当需多个批准时，由最后一位完成评审与合并的人执行合并操作。

二 环境与分支策略

• 环境与工具：
  • 操作系统：Ubuntu 20.04/22.04/24.04 LTS（建议与团队基线一致）。
  • 工具链：git、git-lfs（如涉及大文件）、EditorConfig/Prettier/Black（统一格式）、ShellCheck（Shell 脚本）、hadolint（Dockerfile）、clang-format（C/C++）、eslint（JS/TS）等。
  • 本地 Git 配置建议：开启commit message 规范化（如 Conventional Commits）、pre-commit钩子执行格式与静态检查、git rebase保持线性历史。
• 分支与保护：
  • 分支模型：建议采用Git Flow或Trunk Based Development；长期分支如main/develop，特性分支如feature/，修复分支如hotfix/。
  • 受保护分支：在 GitLab 项目 Settings → Repository → Protected Branches 配置；对main/develop禁止直接推送，仅允许通过MR合并；可设置“Allowed to push”为No one，“Allowed to merge”为Maintainers或特定角色；开启Require approval与Remove source branch等策略。

三 MR 流程与审批规则

• 发起 MR：
  • 源/目标分支正确；标题与描述遵循MR 模板（背景、变更点、影响范围、回滚方案、相关Issue）；指派Reviewer与Assignee；必要时用**@提及相关人；设置必需审批数与里程碑/标签**。
• 评审与迭代：
  • 评审者优先关注设计思路、核心逻辑、边界与异常、可测试性、可维护性、性能与安全；评论应具体、可执行，避免“风格”之争，必要时提供示例或替代实现；作者逐条回应并push 新提交，MR 会自动更新。
• 批准与合并：
  • 按 MR 触及的领域获取相应Reviewer/Maintainer批准；若触及CODEOWNERS定义的范围，需先获取领域专家批准；当需多个批准时，由最后一位完成评审与批准的维护者执行合并；合并前确保CI 全部通过、冲突已解决、关联Issue已关闭或更新。

四 质量标准与检查清单

• 通用标准：
  • 代码与配置变更需有明确目的与最小影响范围；新增或变更功能需配套自动化测试与文档；删除或弃用需有迁移/清理计划与风险提示。
  • 安全合规：输入校验、鉴权与授权、敏感信息不硬编码、依赖漏洞扫描、容器与系统调用最小权限；涉及安全时主动联系 @gitlab-com/gl-security/appsec。
• 语言与框架要点：
  • Shell：遵循ShellCheck规则，使用set -euo pipefail，避免未定义变量与危险命令；路径与权限处理需严谨。
  • Python：遵循PEP 8，使用black/ruff统一格式；类型提示与单元测试覆盖关键路径；依赖安全与版本固定。
  • Node.js：ESLint 规则统一；避免npm audit高危漏洞；环境变量与密钥通过Secrets管理。
  • Docker：使用hadolint检查 Dockerfile；多阶段构建减小镜像；非 root 运行与最小基础镜像；镜像标签不可变。
  • C/C++：clang-format统一风格；静态分析（如 clang-tidy）；资源与内存安全；编译与单元测试通过。
• 变更规模与复杂度：
  • 鼓励小而聚焦的 MR；以下情形可视为“小且简单”，可直接找维护者：
    • 修复错别字或文案微调；
    • 无行为变更的微小重构；
    • 移除已默认启用超过1 个月的特性开关引用；
    • 删除未使用的方法/类；
    • 逻辑清晰且修改少于5 行的变更。

五 推荐配置与度量

• 项目配置：
  • Protected Branches：保护main/develop；禁止直接推送；仅允许Maintainers合并；开启必需审批与删除源分支。
  • CI/CD：在 .gitlab-ci.yml 中配置构建、单元测试、集成测试、静态检查、安全扫描、Docker 构建与推送等流水线；MR 未通过 CI 禁止合并。
  • CODEOWNERS：为关键目录/文件设置领域负责人，确保变更自动指派到合适评审者；涉及安全或特定域的变更优先获取领域批准。
  • 通知与集成：启用邮件/Slack/钉钉等通知；通过Webhook将 MR 事件推送到团队群，减少遗漏；必要时使用IDE 插件（如 IntelliJ GitLab 插件）提升效率。
• 度量与改进：
  • 关注MR 周期时间、评审覆盖率、缺陷率、CI 通过率、回滚率等指标；定期回顾评审规范与流水线策略，持续优化。