在 CentOS 上使用 GitLab 进行代码审查
一 环境准备与安装
- 准备一台 CentOS 7/8 服务器，建议内存至少 4GB，并开放 HTTP/HTTPS(80/443) 与 SSH(22) 端口。
- 安装依赖与邮件服务：
- sudo yum install -y curl policycoreutils-python openssh-server perl postfix
- sudo systemctl enable --now sshd postfix
- sudo firewall-cmd --permanent --add-service=http --add-service=https && sudo firewall-cmd --reload
- 配置清华镜像源并安装 GitLab CE：
- 新建 /etc/yum.repos.d/gitlab-ce.repo，内容：
- [gitlab-ce]
- name=Gitlab CE Repository
- baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el$releasever/
- gpgcheck=0
- enabled=1
- sudo yum makecache && sudo yum install -y gitlab-ce
- 初始化与启动：
- 编辑 /etc/gitlab/gitlab.rb，设置 external_url（如：http://192.168.1.202 或 https://your.domain）
- 如需自定义 Nginx 端口：nginx[‘listen_port’] = 8899
- 执行 sudo gitlab-ctl reconfigure && sudo gitlab-ctl status
- 初始管理员密码：sudo cat /etc/gitlab/initial_root_password（生成后 24 小时自动删除，请尽快修改）
二 建立代码审查流程
- 角色与权限：在项目或 Group 的 Members 中为成员分配角色（如 Guest/Reporter/Developer/Master/Owner），一般让资深成员担任 Master 负责合并，其他成员为 Developer 提交 MR 并接受评审。
- 分支策略与保护：采用 Gitflow 或简化主干开发，在 Settings → Repository → Protected Branches 将 master/dev 等保护分支设置为仅 Maintainers/Masters 可合并，必要时将 Allowed to push 设为 No one，强制通过 Merge Request 变更。
- 开发到合并的标准流程：
- 开发：git checkout -b feature/xxx → 编码自测 → git push origin feature/xxx
- 评审：在 GitLab 创建 Merge Request（MR），指定 Assignee/Reviewers，填写变更目的、测试步骤、关联 Issue，在 Changes 进行 Inline/Side-by-side 评审，提出评论与建议
- 修订：作者根据评审意见 amend/rebase 后再次推送，MR 自动更新
- 冲突：本地合并目标分支解决冲突后推送，继续评审
- 合并与清理：评审通过并由维护者合并，删除已合并的 feature 分支
三 自动化质量门禁与通知
- 服务端提交前校验（Server Hooks）：在 /etc/gitlab/gitlab.rb 配置全局自定义钩子目录并放置脚本，示例：
- gitaly[‘custom_hooks_dir’] = “/opt/gitlab/custom_hooks”
- 创建目录与可执行脚本（如 pre-receive.d/pre-receive），脚本依据语言/工具（如 pylint/checkstyle/pmd）做静态检查，退出码 0 通过、非 0 拒绝推送。该方式对全仓库统一生效，适合强制代码风格与质量基线。
- CI 自动化检查与门禁：安装并注册 GitLab Runner，在 .gitlab-ci.yml 定义 stages（如 build/test/code-quality），通过工具（如 SonarQube/PMD/Checkstyle）产出报告，结合 rules/only/needs 控制何时允许合并；必要时在 MR 流水线中设置 手动批准 或 门禁 阶段，未达标则阻断合并。
- 即时通知：在 Settings → Integrations 配置 Webhook，选择 Merge request events，对接 钉钉/企业微信/飞书 机器人，实现 MR 创建、评审、合并等事件的自动提醒，减少人工通知成本。
四 审查规范与最佳实践
- 分支与提交规范：
- 分支命名：如 feature/、bugfix/、hotfix/、release/，与保护分支配套使用
- Commit Message：采用 Angular 规范（Header/Body/Footer），示例：feat(user): add login validation；保证信息清晰、可回溯
- MR 写作与沟通：
- 描述包含 变更背景、影响范围、测试步骤、回滚方案，关联 Issue
- 控制 MR 体量（建议单 MR 不超过约 200 行变更），便于快速评审
- 评审语气友好、聚焦问题本质，复杂问题建议线下沟通后回到 MR 记录结论
- 合规与自动化：
- 使用 CODEOWNERS 指定目录/文件的必审角色或组，确保关键路径受控
- 启用 流水线事件 与报告展示，结合安全/质量门禁提升合并门槛
- 通过 Webhook 与团队沟通工具联动，形成闭环提醒与追踪
