拉取请求流程

相关源文件

• .github/workflows/links-checker.yml
• .github/workflows/stale.yml
• CONTRIBUTING.md

目的与范围

本文档描述了 Front-End Checklist 项目的完整 Pull Request (PR) 流程，包括提交指南、审核程序和自动化检查。它涵盖了 PR 从初始创建到审核再到最终合并或关闭的整个生命周期。有关初始贡献指南，请参阅 贡献指南，有关问题报告流程，请参阅 问题报告。

来源： CONTRIBUTING.md18-25

PR 提交要求

在向 Front-End Checklist 项目提交 Pull Request 时，请确保您的提交满足以下要求

要求	描述
清晰的描述	解释代码的作用并提供执行步骤
测试	包含代码更改的适当测试
可管理的大小	尽可能将大的更改分解为更小、更集中的 PR
上下文	解释更改的目的以及为何重要

遵循这些指南有助于维护者理解您的贡献，并加快审核过程。

来源： CONTRIBUTING.md18-25

Pull Request 生命周期

上图说明了 Front-End Checklist 存储库中 Pull Request 的完整生命周期，从创建到审核再到合并或关闭。

来源： CONTRIBUTING.md18-25 .github/workflows/stale.yml20-36

拉取请求审查流程

核心维护者会审查 Pull Request，以确保它们符合项目的标准。更小、更集中的 PR 更容易被审核和合并，因此会优先处理。提交 PR 时，提供有关更改重要性的背景信息有助于评审者理解其意义。

审查标准

Pull Request 的评估基于

1. 代码质量和对项目标准的遵循程度
2. 是否包含适当的测试
3. 更改的清晰文档
4. 适当的范围（专注于特定问题）
5. 自动化检查是否成功通过

来源： CONTRIBUTING.md22-25

自动化 PR 管理

Front-End Checklist 存储库利用自动化工作流程来有效管理 Pull Request。

Stale PR 管理

该存储库使用 GitHub 的 Stale action 自动管理不活跃的 Pull Request

• 不活跃 45 天以上的 PR 将被标记为 stale (过时)
• 被标记为 stale 的 PR 在额外的 10 天不活跃后将被关闭
• 带有特定标签（keep-unstale、security、dependabot、wip、need-help）的 PR 将被豁免标记为 stale
• 已分配给维护者的 PR 将被豁免 stale 流程

来源： .github/workflows/stale.yml1-37

高效 PR 的最佳实践

为了确保您的 Pull Request 得到有效审核和合并

1. 保持 PR 集中且小巧：尽可能将大的更改分解为多个 PR
2. 提供背景信息：解释更改为何重要，而不仅仅是更改了什么
3. 包含测试：确保您的更改经过适当的测试
4. 及时响应反馈：及时响应可防止您的 PR 过期
5. 使用适当的标签：添加相关标签以帮助分类您的 PR
6. 引用相关问题：链接到您的 PR 所解决的任何问题

来源： CONTRIBUTING.md18-25

首次贡献者

如果您是项目新手或对开源不熟悉，Front-End Checklist 社区推荐免费课程“如何在 GitHub 上贡献开源项目”作为学习资源。

来源： CONTRIBUTING.md14-16

PR 组件和存储库集成

此图显示了 Pull Request 的不同组件如何与存储库的集成系统交互，包括自动化工作流程和审查流程。

来源： CONTRIBUTING.md18-25 .github/workflows/stale.yml1-37

疑问与支持

如果您对 Pull Request 流程有疑问

1. 查看现有的 issues 看看您的问题是否已被解决
2. 如有需要，请创建一个新问题来提问
3. 请在贡献指南中提供的电子邮件地址直接联系团队

来源： CONTRIBUTING.md32-35