入门指南

本页面将引导您完成前端开发流程，并展示一个正常的合并请求周期是什么样的。您可以在 handbook 中了解更多关于前端团队组织的信息。

第一次提交合并请求需要考虑很多事情，可能会让人感到不知所措。Frontend onboarding course 提供了一个为期 6 周的结构化课程，教您如何为 GitLab 前端做贡献。

开发生命周期

第 1 步：准备 issue

在开始任何工作之前，请仔细阅读分配给您的 issue，并确保所有 required departments 都已按需要参与。根据需要阅读评论，如果不清楚，请在 issue 中发表评论，总结 您认为这项工作是什么，并联系您的工程或产品经理确认。一旦所有内容都明确了，为 issue 应用正确的工作流标签，并创建一个合并请求分支。如果直接从 issue 创建，issue 和合并请求将默认链接起来。

第 2 步：规划您的实现

在编写代码之前，请确保问自己以下问题，并在开始开发之前得到明确的答案：

• 需要什么 API 数据？它是否已经存在于我们的 API 中，还是我应该询问后端同事？
  • 如果这是 GraphQL，请编写查询提案并询问您的后端同事确认他们是否同意。
• 我可以使用 GitLab UI 组件 吗？哪些组件是合适的，它们是否具有我需要的所有功能？
• GitLab 项目中是否有我可以使用的现有组件或工具？
• 此更改是否应该通过 Feature Flag 来控制？
• 这段代码应该放在哪个目录中？
• 我是否应该将此功能的一部分构建为可重用的？如果是，它应该位于代码库的哪个位置，我如何使其可被发现？
  • 注意：目前这仍在考虑中，但 vue_shared 文件夹仍然是 GitLab 全局组件的首选目录。
• 它需要什么类型的测试？考虑单元测试 和 Feature Tests？我应该联系 SET 寻求指导，还是我自己可以舒适地实现测试？
• 这个更改会有多大？尽量将差异控制在 最多 500 行。

如果所有这些问题都有答案，那么您可以安全地继续编写代码。

第 3 步：编写代码

在您进行工作或长期无法处理计划中的 issue 时，请确保与您的团队保持沟通。

如果您需要帮助，请确保推送您的分支，并将您的合并请求直接分享给团队成员或在 Slack 频道 #frontend 中分享，以获取如何前进的建议。您可以 将您的合并请求标记为草稿，这将清楚地表明它还准备进行完整审查。请始终记住保持 低水平的羞耻感，并在需要时 寻求帮助。

在编写代码时，请确保彻底测试您的更改。作者有责任测试自己的代码，确保它按预期工作，并确保它没有破坏现有行为。审查者可能会在这方面提供帮助，但 不要期望他们这样做。请确保检查不同的浏览器、移动视口和意外的用户流程。

第 4 步：审查

当是时候将您的代码送去审查时，这可能会相当令人紧张。建议阅读 代码审查指南，以更好地了解预期。其中最宝贵的建议之一是 必不可少的：

… 为了避免与审查者之间不必要的来回沟通，… 请对自己的合并请求进行自我审查，并遵循代码审查指南。

这是获得良好合并请求体验的关键，因为您会发现小错误并在审查者可能不确定和有疑问的地方留下评论。这极大地加快了整个过程。

第 5 步：验证

当您的代码合并后（恭喜！），请确保验证它在生产环境中正常工作，并且不会引起任何错误。