gitlab的merge request（mr）是代码进入关键分支前必须经过的审查关卡，而非快捷提交方式；必须配合分支保护（allowed to push设为no one、allowed to merge限maintainers）才能生效，否则可被直接push绕过；mr描述需含why/what/how to test三要素，assignee应为责任归属者，审批后须确认ci全绿、分支最新、批准数达标且无调试残留。
GitLab 的 Merge Request（MR）不是提交代码的快捷方式，而是代码进入关键分支前必须经过的审查关卡。跳过 MR 直接 push 到 main 或 develop，等于绕过安检把未验货的包裹塞进生产仓库——出问题只是时间问题。
为什么 MR 必须绑定分支保护
没开分支保护的 MR 形同虚设。即使你创建了 MR，别人仍能绕过它直接 git push 到目标分支。真正的防线在 Settings → Repository → Protected Branches 里：
-
Allow to push必须设为No one（尤其对main、develop、release/*） -
Allow to merge只给Maintainers或指定审批组，不能开放给所有Developers - 如果团队用
feature/*分支，feature/前缀本身无需保护，但它的目标分支（如develop）必须受保护
常见错误：只开了 main 保护，却放任 develop 可被直接 push —— 这样 MR 审查就只拦住了上线，拦不住集成污染。
MR 描述怎么写才不被秒拒
一个空着 Description 或只写“fix bug”的 MR，大概率会被打回重填。评审人不是猜谜选手，需要明确上下文：
- 第一行必须是清晰的变更目的，例如：
feat(auth): add SSO login via OIDC - 描述区至少包含三要素：
Why（为什么改）、What（改了什么）、How to test（怎么验证，比如 “本地启动后访问 /login，确认跳转到 Auth0”） - 关联任务时用
Resolves #123或Closes gitlab-org/gitlab#45678，GitLab 会自动关闭对应 issue - 避免截图堆砌；真有必要展示 UI 变更，用 GitLab 内置的 diff 截图功能，别传外链图
注意：Title 不是备注栏，它会出现在合并后的 commit message 里。别写“update README”，而要写“docs: update API auth section with new token flow”。
谁该被 assignee，谁该被 @mention
Assignee 是唯一对 MR 合并决策负最终责任的人，不是“看看就行”的人。选错 assignee 会导致流程卡死：
- 功能类 MR：assignee 应是该模块的长期维护者，或当前迭代的技术负责人
- 紧急 hotfix MR：assignee 必须是当前 on-call 的 SRE 或后端主程，且需同步
@mention所有涉及服务的 owner - 跨多模块修改（如同时动前端路由 + 后端鉴权 + DB migration），assignee 应是本次发布 owner，而非单个开发者
- 不要把 MR assignee 设为自己——除非你是项目唯一 Maintainer，否则这等于放弃集体责任
额外提醒：@mention 在 description 或 comment 里触发通知，但不会赋予审批权限；只有被设为 assignee 或在审批规则中配置的 reviewer 组，才有“Approve”按钮。
MR 被 approve 后，merge 前还差哪几步
点下 “Approve” 不等于万事大吉。GitLab 默认允许直接 merge，但严谨流程必须加锁：
- 检查 CI 状态是否全绿 —— 特别注意
test:e2e和lint:security这类耗时长、易被忽略的 job - 确认 target branch 自从 MR 创建后没有新 commit 推入（页面右上角会提示 “This merge request is not up-to-date”）；若有，必须 rebase 或 merge
target分支进来，再重新跑 CI - 如果启用了 “Require at least X approvals”，确保审批数达标且来自不同用户（GitLab 默认禁止 self-approval）
- 最后点击 “Merge” 时，勾选
Squash commits（除非你明确需要保留原子提交历史），避免把 feature 分支的 17 次调试提交全塞进main
最容易被跳过的细节：没人检查 MR 的 “Changes” 标签页里有没有意外带入调试代码（比如 console.log、debugger、临时注释掉的 config）。自动化 lint 可以拦一部分，但人工扫一眼 diff 仍是不可替代的一步。
