开发流程

查看这些主题，了解为 GitLab 做贡献的开发流程信息。

流程

必读：

• 关于调整现有组件和引入新组件的指南
• 代码审查指南，用于审查代码和接受代码审查
• 数据库审查指南，用于审查数据库相关更改和复杂 SQL 查询，并接受审查
• 安全编码指南
• GitLab 项目的流水线
• 避免必需的停止点

补充阅读：

• 为 GitLab 做贡献
• 开发者的安全流程
• 开发者的补丁发布流程
• 实现企业版功能指南
• 向 GitLab 添加新的服务组件
• 变更日志指南
• 依赖项
• Danger 机器人
• 请求访问 GitLab.com 上的 ChatOps（适用于 GitLab 团队成员）

开发指南审查

对于开发指南的更改，请向有经验的 GitLab 团队成员请求审查和批准。

例如，如果您正在记录某个组专用的内部 API，请向该组的成员请求工程审查。

小修复，如拼写错误，可以由任何至少拥有 Maintainer 角色的用户合并。

更广泛的更改

某些更改会影响多个组。例如：

• 代码审查指南 的更改。
• 提交消息指南 的更改。
• GitLab 开发中的功能标志 中的指南更改。
• 功能标志文档指南 的更改。

在这些情况下，使用以下工作流程：

1. 向您的团队成员请求同行审查。

2. 请求负责相关领域的工程经理（EM）或高级工程师进行审查和批准：

   • 前端
   • 后端
   • 数据库
   • 用户体验 (UX)
   • 安全
   • 质量
     • 工程生产力
   • 基础设施

   对于由负责各自领域的 EM 或高级工程师创建的 MR，您可以跳过此步骤。

   如果有多个受影响的组，您可能需要每个受影响领域的 EM/高级工程师级别的批准。

3. 完成审查后，与 MR 的作者/批准者（EM/高级工程师）协商。

   如果这是跨多个领域的重大更改，请向开发副总裁请求最终审查和批准，他是开发指南的 DRI（直接责任人）。

任何 Maintainer 都可以合并 MR。

技术写作审查

如果您希望技术作家进行审查，请在 #docs Slack 频道中发布消息。 但是，技术作家不需要审查内容，任何 MR 作者之外的 Maintainer 都可以合并。

审查者价值观

作为审查者或被审查者，请务必熟悉我们在 GitLab 努力实现的 审查者价值观。

此外，任何文档内容都应遵循 文档风格指南。

语言特定指南

Go 指南

• Go 指南

Shell 脚本指南

• Shell 脚本标准和风格指南

清晰的书面沟通

在编写问题或合并请求中的任何评论或其他任何形式的交流时，使用 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 等术语时，请遵循 IETF 标准。

这确保了来自不同文化的不同团队成员能够清楚地理解所使用的术语。