mr是质量控制第一关，必须绑定ci检查、强制模板化描述、指定具备模块上下文的reviewer、合并后自动删除源分支，并确保每次mr可追溯可问责。
合并请求（Merge Request，MR）不是代码合并的终点，而是质量控制的第一道关卡。跳过审查、绕过CI、直接合入 develop 或 main 分支，等于把测试和评审责任甩给下游——问题往往在集成测试或上线后才暴露。
为什么 MR 必须绑定 CI 检查
CI（持续集成）不是可选项，它是 MR 的准入门槛。没有通过 .gitlab-ci.yml 定义的流水线（比如单元测试、lint、类型检查），MR 就不该被允许合并。
- GitLab 默认允许手动覆盖 CI 状态，但生产环境仓库必须关闭
Allow pipeline to be skipped选项 - Python 项目建议至少包含
pytest+black+mypy三阶段检查，失败项直接阻断 MR 合并按钮 - CI 运行环境需与目标分支一致：合入
develop用develop的依赖版本，而非本地开发时的临时版本
MR 描述不写清楚，等于没提 MR
一个空着 Description 或只写“fix bug”的 MR，审查者无法判断变更范围、是否影响核心逻辑、有没有遗漏边界 case。
- 强制模板化：在 GitLab 项目设置里启用
Merge request template，预置字段如「关联 Issue」、「影响模块」、「测试方式」、「回滚方案」 -
git commit -m的内容不会自动同步到 MR 描述，必须人工补全；尤其注意说明「为什么改」，而不仅是「改了什么」 - 截图、日志片段、前后行为对比（比如 API 响应变化）比文字更直观，可直接粘贴进 MR 描述区
谁该被指定为 Reviewer 不是随便点的
Reviewer 不是凑数角色，必须对所审代码的模块有上下文认知。让前端工程师审数据库迁移脚本，或让新人审权限系统逻辑，都属于责任错配。
- GitLab 支持基于路径的自动 assign：在
.gitlab-ci.yml或项目设置中配置CODEOWNERS文件，例如：src/auth/** @backend-team docs/ @tech-writer
- 禁止单人 approve 后立即合并：至少需 1 名非作者 + 1 名模块 owner（可通过分支保护规则强制）
- MR 被修改后（如 rebase 或 force-push），原有 approval 自动失效，必须重新审查
合并后删分支不是仪式感，是防误操作
保留已合并的 feature/xxx 分支，会干扰后续 git branch -a 查看、增加 cherry-pick 错分支风险、甚至被误当成新基线再次开发。
- GitLab MR 页面勾选
Delete source branch when merge request is accepted是默认推荐选项 - 本地也要同步清理：
git checkout main && git pull && git branch -d feature/login，否则下次拉取远程分支时仍会看到它 - 如果 MR 被拒绝而非合并，分支不能删——但要加标签注明状态，比如重命名成
archived/feature-login-rejected
真正难的不是发起 MR，而是让每次 MR 都成为一次可追溯、可验证、可问责的质量切片。没人会盯着你写的每行代码，但 MR 的标题、描述、CI 状态、Reviewer 记录、合并时间，全都会留在 GitLab 的审计日志里——这些才是团队信任的真正来源。
