拉取请求¶

WebKit 项目对拉取请求的格式有一些要求。这些要求被编入了 Tools/Scripts/git-webkit pr 中，贡献者可以在本地草拟更改后运行此工具来配置拉取请求。WebKit 项目建议您遵循并利用我们的工具。如果贡献者希望使用其他工具，本文档将解释 Tools/Scripts/git-webkit pr 的作用以及 WebKit 对拉取请求的格式要求。

错误跟踪¶

大多数拉取请求的第一步是创建一个错误报告。虽然并非每个拉取请求都需要一个独特的错误报告，但每个已落地提交都应能追溯到其关联的错误报告。特别是，回归或后续修复的拉取请求通常会引用原始提交所引用的错误报告。

分支管理¶

拉取请求分支由其作者拥有，这就是为什么 git-webkit setup 会创建 WebKit 的个人分支。这意味着 WebKit 项目无法强制执行分支惯例，尽管 WebKit 团队有一些建议，以便其他贡献者可以更轻松地访问提议的更改。Tools/Scripts/git-webkit pr 会根据与拉取请求关联的错误报告标题派生出以 eng 为前缀的分支。

我们建议拉取请求的分支名称以 eng/ 或 dev/ 为前缀，这样当贡献者将其他用户的派生作为远程仓库添加时，就能清楚地知道哪些分支包含生产代码。值得注意的是，EWS 无法应用来自其目标分支的更改（即，EWS 无法将来自 Contributor/WebKit:main 的更改应用到 WebKit/WebKit:main），因此为了进行审查，更改必须来自不同的分支。

提交信息¶

WebKit 项目高度依赖提交信息来维护项目的性能和正确性，并用它们来管理发布。为此，WebKit 项目要求每个提交信息中包含以下内容：

错误标题
错误 URL
审查者（或明确说明更改未被审查的原因）
高级别解释（可选）
文件更改、更改内容和原因

git-webkit setup 会配置 .git/prepare-commit-msg，以便您的提交信息模板符合 WebKit 项目的标准。

除了拉取请求的提交应包含详细的提交信息外，WebKit 项目还要求拉取请求描述中包含提交信息的内容。这是为了让审查者能够对提交信息本身提供反馈。

审查¶

提交通常需要审查者的批准，但测试预期修正和构建修复有少量例外。审查者将通过 GitHub UI 将拉取请求标记为“Approved”（已批准）来批准拉取请求。请注意，非审查者的批准将不会被合并队列识别。

落地¶

只有仓库管理员拥有直接提交权限，这仅用于修复基础设施问题。拉取请求应通过合并队列进行落地，这通过为您的拉取请求应用 safe-merge-queue、merge-queue 或 unsafe-merge-queue 标签来实现。

每个队列都会通过将所有已批准拉取请求的审查者姓名添加到提交信息中，来确保更改已被审查。然后，它会检查提交信息中是否包含 Reviewed by。

请注意，合并队列将拒绝由非提交者标记的拉取请求。非提交者可以使用 request-merge-queue 标签，让审查者将更改添加到队列中。