在 Devin 中试用 DeepWiki 处理私有仓库
DeepWiki

Anduin2017/HowToCook

菜单

拉取请求流程

相关源文件

本文档详细介绍了在 HowToCook 仓库中提交和处理 Pull Request (PR) 的端到端流程。它涵盖了 PR 提交工作流程、自动化检查、审查流程以及 PR 合并后会发生什么。有关质量控制机制和特定 lint 规则的信息，请参阅质量控制。

概述

HowToCook 仓库采用标准化的 Pull Request 流程，以确保所有贡献都保持一致的质量和格式。此流程包括验证格式规则的自动化检查、许可协议要求以及人工审查阶段。

拉取请求工作流程

来源: .github/pull_request_template.md1-15 .github/workflows/ci.yml1-18 .github/workflows/build.yml1-49

创建拉取请求

在为 HowToCook 仓库贡献内容创建 Pull Request 时，您需要遵循以下指南

  1. Fork 该仓库并为您的更改创建一个分支
  2. 按照仓库的格式指南进行更改
  3. 提交一个指向 master 分支的 Pull Request

拉取请求模板

当您创建 PR 时，会自动应用一个模板，其中包含您必须完成的重要复选框

## 注意

Pull Request 提交后，预计 1 分钟内将会得到自动化格式检查的结果。只有通过自动化检查的 Pull Request 才会被人工审核。

- [ ] 请确保此 Pull Request 能够通过自动化代码检查。

## 签署

必须签署下面的对话框才能开始审核。

### HowToCook 仓库采用了 [The Unlicense](https://unlicense.org/) 协议

菜谱在签入前，必须确保其可以**直接声明进入 "公共领域"（public domain)**。这意味着一旦合并后，任何人都**可以**自由复制，修改，发布，使用，编译，出售或以菜谱的形式或菜的形式分发，**无论**是出于**商业目的**还是**非商目的**，以及**任何**手段。

- [ ] 我确保了我的内容不涉及版权内容，并且授权它 The Unlicense 协议。

此模板要求您

  1. 承认您的 PR 必须通过自动化检查
  2. 确认您的内容不侵犯版权，并同意将其许可在 The Unlicense 下

来源: .github/pull_request_template.md1-15

许可要求

HowToCook 仓库使用The Unlicense，它有效地将所有贡献都置于公共领域。通过选中 PR 模板中的复选框，您确认

  1. 您的内容不包含受版权保护的材料
  2. 您同意将您的贡献置于公共领域
  3. 您理解一旦合并，任何人都可以出于任何目的（包括商业目的）自由使用、修改或分发您的贡献

来源: .github/pull_request_template.md11-15

自动化检查

提交 PR 后，GitHub Actions 将自动触发 .github/workflows/ci.yml 中定义的持续集成 (CI) 工作流。此工作流执行多项自动化检查，以确保您的贡献符合仓库的质量标准。

CI 工作流流程

来源: .github/workflows/ci.yml1-18 package.json16-22

代码检查流程

npm run lint 命令运行三个独立的 linting 工具

  1. textlint: 检查与文本相关的格式问题

    • 使用为处理日文和中文文本定义的规则
    • 修复半角和全角字符之间的间距
    • 验证括号使用

  2. markdownlint: 验证 markdown 格式

    • 检查一致的 markdown 语法
    • 使用 .markdownlint.json 中定义的规则

  3. manuallint: 自定义 linting 脚本

    • 实现仓库特定的验证规则
    • 检查所需的章节结构
    • 确保食谱中的测量和格式准确

来源: package.json16-22 .markdownlint.json1-8

了解 CI 失败

如果您的 PR 未通过自动化检查，您需要

  1. 检查 CI 日志以识别具体问题
  2. 在您的分支中进行必要的更正
  3. 推送更改以更新您的 PR
  4. 等待 CI 进程再次运行

在所有自动化检查通过之前，PR 将不会进入人工审查阶段。

来源: .github/pull_request_template.md1-5 .github/workflows/ci.yml1-18

审查和合并流程

在您的 PR 通过所有自动化检查后，它将由仓库维护者进行审查。这次人工审查确保您的贡献达到了自动化检查无法验证的质量标准。

人工审查标准

虽然具体标准可能因您的贡献性质而异，但审查者通常会关注

  1. 内容质量：食谱是否清晰、准确且结构良好？
  2. 事实准确性：烹饪说明是否准确且安全？
  3. 完整性：食谱是否包含所有必要信息？
  4. 一致性：它是否遵循仓库中其他食谱的风格和格式？

反馈和迭代

审查者可能会提供反馈，要求更改您的 PR。如果发生这种情况

  1. 查看反馈意见
  2. 进行必要的更改
  3. 将更新推送到您的分支
  4. PR 将会再次被审查

这个循环可能会重复，直到审查者对您的贡献满意为止。

合并流程

获得批准后，仓库维护者会将您的 PR 合并到 master 分支。此操作将触发持续部署 (CD) 工作流。

合并后部署

当 PR 合并到 master 分支时，它会触发 .github/workflows/build.yml 中定义的 CD 工作流。此工作流更新仓库的文档并部署更改。

CD 工作流流程

来源: .github/workflows/build.yml1-49

README 文件重新生成

CD 工作流运行 npm run build 命令，该命令执行 .github/readme-generate.js。此脚本

  1. 处理仓库中的所有食谱文件
  2. 使用所有食谱的链接更新主 README.md 文件
  3. 更新根据难度对食谱进行分类的星级系统文件

Docker 部署

更新文档后，工作流

  1. 构建包含更新后的仓库的 Docker 镜像
  2. 将其标记为 ghcr.io/anduin2017/how-to-cook:latest
  3. 将镜像推送到 GitHub Container Registry
  4. 使其可供公众使用

来源: .github/workflows/build.yml32-49

常见问题排查

以下是 PR 过程中常见的问题及其解决方法

问题可能原因解决方案
Lint 失败格式不正确、缺少章节、测量不当检查 CI 日志以获取具体错误，并根据仓库标准进行修复
缺少复选框确认忘记勾选 Unlicense 协议框编辑 PR 描述并勾选所需复选框
审查后请求更改内容需要改进或不符合指南处理审查者意见并更新您的 PR
合并冲突自创建分支以来，master 分支已发生更改rebase 或将 master 合并到您的分支以解决冲突

来源: .github/pull_request_template.md1-15 .github/workflows/ci.yml1-18

监控您的 PR 状态

您可以通过以下方式监控您的 PR 状态

  1. 检查 GitHub PR 页面上的自动化检查结果（显示为 ✓ 或 ✗ 图标）
  2. 查看维护者的任何评论
  3. 及时回复反馈，以加快审查流程

一旦您的 PR 被合并，您可以通过检查以下内容来验证您的更改是否已成功部署

  1. 仓库主页面上更新的 README.md 文件
  2. 相应的星级系统分类文件
  3. 网站 https://cook.aiursoft.cn （已从最新的 Docker 镜像更新）

来源: .github/workflows/build.yml1-49 package.json28