GitLab Topic
GitLab Issues、Boards 与 Milestones
理解 GitLab 如何用 issue、board 和 milestone 把计划、流转和交付组织起来，而不是把所有上下文都塞进 Merge Request。
- 已经会基础 Git、准备系统学习 GitLab 协作的人
- 要在团队里使用 Merge Request、Issue Board 和 CI/CD 的开发者
- 知道 branch、commit、push、remote 的基本作用
- 愿意把平台功能和 Git 操作一起理解
- 只记 GitLab 页面操作却忽略底层 Git 边界
- 把平台策略误当成可以替代本地历史判断
为什么不能只看 Merge Request
如果团队只围绕 Merge Request 工作，就很容易把计划背景、任务流转和交付节奏全部丢进代码评审里。
GitLab 的 issue、board 和 milestone，就是为了把这些语义从 diff 页面里分离出来。
issue 负责说明工作本身，board 负责呈现流转，milestone 负责表达时间或版本目标。Merge Request 更适合承担实现和评审，而不是背全部协作语义。
这三层分别负责什么
Issue：一个具体问题、需求、缺陷或任务入口Board：把 issue 按当前状态组织成可视化流程Milestone：把工作与某个版本、阶段或时间点关联起来
它们不是多余容器，而是让计划、执行、交付各自有更清晰的位置。
一条更成熟的协作线
- 先创建或补充 issue
- 把 issue 放到 board 的对应状态里
- 在流转过程中持续更新 board
- 如果交付时间重要，再把 issue 绑定到 milestone
- 最后通过 Merge Request 实现并回链 issue
这样做的价值是：代码评审不需要替代任务管理。
团队能得到什么
- reviewer 可以先看 issue 理解业务背景，而不是只盯 diff 猜意图
- 负责人可以从 board 看到堵点，而不是逐个点开 MR
- 交付节奏可以通过 milestone 体现，而不是靠大家口头记忆
常见反模式
- 只开 MR，不建 issue
- board 只在搭建时更新，后面形同虚设
- milestone 只是有名字和日期，但没有真实计划意义
- 把非代码工作全都排除在系统外，导致流程只剩“写代码”
一个够用而稳的实践基线
很多团队用下面这套就已经很有效：
- issue 只表达一个真实工作单元
- board 列反映真实流程，而不是理想化名词
- milestone 只在“时间或版本目标真的重要”时使用
- Merge Request 引用 issue，而不是替代 issue
四列真实可维护的 board，通常比十列没人更新的“精致流程图”更有价值。先保证可见性，再谈复杂流程。
它如何直接提升评审质量
一旦 issue 和 board 管得健康：
- MR 就可以更聚焦在实现本身
- reviewer 不需要反复追问“这到底在解决什么”
- 工作优先级和流转状态在代码评审前就已经可见
真正的价值不是“有了 board”，而是降低了协作歧义。
图例理解
IssueBoard 状态Milestone 目标
Merge Request可见状态版本分组
一旦所有信息都压进 MR，计划和交付上下文通常就会越来越难维护。
边界与判断
- 不是每个 issue 都需要 milestone，但每个 milestone 都应该有真实含义
- board 应该反映真实团队流转，而不是理想化口号
- MR 会因为 issue 上下文更清楚，而更容易评审
如果 board 不再被诚实更新，它就不再是协作基础设施，而会变成一种误导团队判断的装饰品。
跟着做一遍
目标是让工作在进入 Merge Request 之前就已经被看见和组织起来。
选一个小需求或缺陷。 为它创建 issue。 准备一个只有少量真实状态列的 board。动手试
- 先在 issue 里写清楚问题和目标。
- 把它放进 board 的真实当前状态。
- 只有在时间目标重要时才绑定 milestone。
- 打开一个回链该 issue 的 Merge Request。
- 合并后再检查 board 和 milestone 是否仍然准确。
- 团队可以在读代码前先理解工作本身。
- board 能成为真实的流转信号。
- milestone 更像交付管理工具，而不是装饰字段。
- 如果 issue 很模糊，MR 通常也会跟着模糊。
- 如果所有任务都加 milestone，milestone 就会失去筛选价值。
- 如果 board 长期不更新，团队很快就不会再信它。