合并请求模板（GitLab）
GitLab 用固定目录存放合并请求模板，新建时从描述框上方的下拉里选择。仓库级模板随仓库一起版本化，实例级模板由管理员统一配置，适合在组织范围内统一规范。多个模板分别对应不同类型的变更，比一个超长模板实用得多。
基本信息
| 仓库级 | .gitlab/merge_request_templates/<名称>.md |
|---|---|
| 实例级 | 管理员在实例管理区域配置默认模板 |
| 选择方式 | 新建合并请求页面的模板下拉 |
| 优先级 | 同时存在时以仓库级配置为准 |
典型使用场景
- 为缺陷修复、发布、实验特性分别提供模板
- 组织范围内统一默认模板，减少每个仓库重复配置
- 通过模板提示补充测试与回滚说明
- 在模板里预留关联问题编号的写法
- 让不同类型变更的评审要点各不相同
目录结构示例
目录结构示例
.gitlab/
merge_request_templates/
Default.md
Bugfix.md
Release.md层级对照
| 层级 | 位置 | 适用 |
|---|---|---|
| 仓库级 | 仓库内的固定目录 | 单个仓库的约定 |
| 实例级 | 实例管理区域 | 组织范围的统一规范 |
| 选择方式 | 新建页面下拉 | 每次创建时手动选择 |
多个模板适合不同类型的变更（缺陷修复、发布、实验特性），每个模板保持在十行以内更实用。
模板只在新建时载入，创建之后可以被任意改写；真正必须满足的条件应交给审批规则与流水线。
模板写法建议
- 只保留必须由人填写的检查项，其余交给流水线
- 为每类变更写清需要补充的信息，例如测试与回滚
- 模板文件纳入版本管理，修改走正常的评审流程
- 更新模板后通知团队，避免各处的版本长期不一致
把模板当成一份简短的提问清单：写的人知道要交代什么，评审的人知道该看哪里，几十行以上的模板反而没人愿意读。