议题与合并请求：把问题讨论和文件修改连接起来

两类记录解决不同问题

在 GitLab 中，Issue 可承载任务、缺陷、建议和支持请求；Merge Request 则集中展示拟议修改、讨论、提交及相关流水线信息，两者可互相建立关联。功能依据分别见 Issues 文档 和 Merge requests 文档。

对搜索“海角网gitlab”后开始读协作页面的人，建议把它们理解为两份互补记录：一份把问题讲清，一份把修改摆出来。并非每个问题立即有修改方案，也并非每次小修改都需要长篇需求讨论。

用四个问题比较阅读重点

这是一套阅读建议，不是强制规定项目必须采用的工作流。遇到团队已有说明或模板时，应优先按其写法理解字段，不把自己熟悉的习惯当成该项目的承诺。

教学案例：修正文档中的路径

虚构例子：一份入门文档把配置目录写为 config-old/，读者按步骤找不到文件。议题可以写明文档路径、所读版本、尝试步骤和实际目录；目标是让新读者能按说明完成配置。随后，一个合并请求把路径改为 config/，并同步修正两处示例。

只读议题，你知道问题是什么；只读差异，你知道三个位置被改过。把两者一起看，才能检查修改是否覆盖了原问题。若还有一张截图保留旧路径，文本修改本身正确，整体文档仍可能不一致。这类遗漏需要对照目标发现。

关闭、合并和上线要分别理解

看到关闭状态后，继续读结论文字：是重复报告、暂不处理、需求变化，还是已通过修改解决？看到合并请求已合并，也应核对它合入哪个分支。若你使用的版本来自另一个标签或尚未更新的发布物，就不能推断自己的问题已经消失。

判断进展时可以写一条证据链：“议题描述的现象 → 关联修改 → 变更中的对应位置 → 验证记录 → 我使用版本的适用性”。缺少哪一环，就把哪一环标为待确认。这样比仅引用一个绿色状态更便于协作。

参与讨论时让信息落在合适位置

• 新增独立问题：先查已有议题，避免把另一种现象混在原线程里。
• 询问某段修改：引用准确文件及行附近上下文，描述期望行为。
• 反馈仍然存在：补充正在使用的版本和可复现条件。
• 确认已解决：说明复测范围，不把一次成功扩大为所有环境均通过。

结论是保持问题、修改和验证之间的可追溯关系。协作记录的价值来自可理解的上下文，而不是评论数量或状态颜色。