拉取请求
最后更新于
最后更新于
Pull Requests（拉取请求）是我们用来编写软件的主要机制。GitHub 有一些关于使用 Pull Request 功能的精彩。
每个新功能或错误修复都应该在单独的分支上开发。分支允许您同时处理多个功能。在大多数情况下，您应该从 master 分支。但是，如果您与其他贡献者合作，我们通常会分支出一个长期存在的功能分支。长期存在的功能分支允许我们将单个功能分解为多个 PR，这些 PR 可以单独审查，但可以一起测试和发布。
作为 Bitwarden 贡献者，您应该分支 origin/master，这确保分支始终基于最新的上游 master 即使本地 master 已过时。
详细描述了我们的分支策略。
我们建议将相关更改分组到单个提交中。这可以使审阅者更容易理解和评估所提议的更改，同时还可以为贡献者提供检查点，以便在出现问题时可以恢复。
我们没有关于如何构建提交消息（例如语义提交消息）的标准。我们鼓励提交消息应在 50 个字符的限制内，以便可以轻松使用 git log。如果提交消息需要超过 50 个字符，最好将其分解为更小的原子更改，以提高 git 历史记录的可读性和可延展性（还原、挑选等）。
更高级的贡献者可能会发现很有用。这允许贡献者在推送到远程存储库之前修改其本地历史记录。一个常见的用例是压缩多个半工作提交。请务必遵循强制推送建议。
PR 被审查后，就应避免强制推送。
影响现有 git 提交的 Git 操作会阻止 GitHub 正确识别 PR 的「新的更改」，迫使审阅者重新开始。
Bitwarden 存储库有一个应遵循的 Pull Request 模板。这将确保 PR 审核顺利进行，因为它将为审核者提供背景信息。创建社区 PR 后，它们将自动链接到内部 Jira 票证。内部票证用于确定优先级和跟踪目的。将 @dept-design 标记为任何 UI 更改的审阅者。
虽然我们主要使用异步审查流程，但请随时安排与审查者/贡献者的会议来讨论更改。虽然异步通信很有用，但它会带来时间损失，从而拖延审查过程。有时，召开简短的电话会议来讨论更改可能会节省大量时间。
我们编写了一些，建议您在执行第一次代码审查之前阅读这些指南。