Ubuntu 上使用 GitLab 进行代码审查的标准流程
在 Ubuntu 环境中，GitLab 的代码审查以 Merge Request（合并请求，简称 MR） 为核心。开发者在特性分支完成改动后推送到远端，在 GitLab 上创建 MR 指向目标分支（如 develop 或 main），由审阅者进行评论、提出变更建议，满足审批与 CI 检查后由具备权限的成员完成合并。为提高效率，建议配合 受保护分支、CI/CD 自动化 与 IDE 插件 一起使用。
一、环境与权限准备
- 安装与初始化：在 Ubuntu 上部署 GitLab（如使用 Omnibus 安装），设置 EXTERNAL_URL 并运行
sudo gitlab-ctl reconfigure 完成初始化。确保系统时间、磁盘与网络正常。
- 角色与权限：至少准备 Developer（可推送与创建 MR）与 Maintainer（可合并与配置受保护分支）两类角色，用于隔离提交与合并权限。
- 受保护分支：在项目 Settings → Repository → Protected Branches 中，将 main/develop/release 等分支设为受保护，仅允许通过 MR 合并，禁止直接 push；必要时仅对 Maintainers 开放 Merge 权限，杜绝绕过审查的本地合并后推送行为。
二、日常审查流程
- 创建分支与提交：从 develop/main 拉出 feature/ 或 bugfix/ 分支，完成编码与本地自测后推送至远端：
git push -u origin feature/xxx。
- 发起 MR：在 GitLab 项目页面选择 Merge Requests → New merge request，设置 Source branch 与 Target branch（如 feature → develop），填写 Title/Description，通过 @ 指派 Assignee/Reviewer，并配置 Approvers 与 Approvals required（批准人数）。
- 在线审查与讨论：审阅者在 Changes 页面对代码行发表评论、建议修改或提出阻塞问题；讨论可标记为 Resolved；必要时使用 Web IDE 进行快速在线修改。
- 冲突处理：若存在 Merge conflict，开发者需先在本地将目标分支合并到特性分支解决冲突，再
git push 更新 MR。
- 合并与清理：当 审批通过、CI 检查通过 且 流水线成功 后，由 Maintainer 点击 Merge 完成合并；可选择 Remove source branch 清理特性分支。
三、自动化与质量门禁
- 配置 CI：在项目根目录添加 .gitlab-ci.yml，定义 test/lint/build 等阶段，保证合入前通过自动化验证（如单元测试、静态检查、构建）。
- 代码风格与静态检查：在 CI 中加入 Checkstyle/SpotBugs/ESLint/golangci-lint 等工具，统一规范并阻断不合规提交。
- 合并前置条件：在 Settings → Merge requests → Merge checks 启用“Pipelines must succeed”“Approvals required”等选项，确保只有通过 CI 与审批的 MR 才能合并。
四、效率工具与最佳实践
- IDE 集成：使用 JetBrains 系列 IDE 的 GitLab Projects / GitLab Integration 插件，直接在 IDE 内创建 MR、查看差异、管理评论与合并，减少上下文切换（注意：行级讨论与解决在网页端更完善）。
- 模板与规范：启用 Issue/Merge Request 模板，在 MR 描述中说明变更背景、影响范围、测试要点与截图，提升审阅效率与一致性。
- 分支与颗粒度：遵循 Git Flow 或 Trunk Based Development 的分支策略，保持 MR 颗粒度适中（一次聚焦一个功能/修复），便于审阅与回溯。
- AI 辅助：结合 GitLab Duo Chat 快速解释代码、生成示例或定位问题，提高审查速度与质量。
