这是我按照系统架构中所述编写的 4 个脚本中的第一个。感觉很抽气！这是朝着创建“wiki”体验方向迈出的一步，无需与 GitHub UI 交互即可为开源做出贡献？.

这些脚本是什么？

这些 js 文件包含一些相关的可重用函数，特别是用于与 GitHub API 交互；它们要么在同一脚本中使用，要么导出以用于在项目中的其他地方执行其基本功能。他们接受经过身份验证的用户 Octokit 实例作为其他人的参数，该实例用于代表经过身份验证的用户通过 GitHub API 执行操作/功能。

需要创建一个在不与 GitHub UI 交互的情况下为开源做出贡献的流程，这意味着我们必须自动化一些流程 - 模拟用户通过 GitHub UI 做出贡献时将采取的每一个步骤，步骤如下接下来..

1. 分叉项目仓库
2. 创建分支
3. 将更改提交到分支（在 src/pages/word/ 目录中添加新的 mdx 文件以获取新单词或编辑现有文件，在我们的例子中）
4. 创建拉取请求（在我们的例子中提交单词更改）

一个值得陈述的真理

我在初次提交后就开始编写这个脚本，这实际上是 PR #2，但在漫长的一个月休息期间它受到了打击？在重新开始开发基本字典功能之前，我从该项目中获取了一些信息。

脚本

这里的任务是创建“The Fork Script”——其最终目标是在用户帐户上创建/获取 jargons.dev 存储库的分叉。它应该包含执行以下操作的每个函数。

• 检查用户帐户上是否已存在 jargons.dev 的 Fork
  • 如果分叉存在
    • 检查 Fork 是否与上游同步（即与 jargons.dev 存储库主分支保持同步）；如果不是 — 更新 fork
  • 如果没有找到叉子
    • 创建分叉

理解了作业后，我直接“钻研”到了剧本上。

由于我在 Hearts 的日常工作中频繁使用，我已经非常习惯 GitHub API 了❤️...所以我的 GitHub 的 Fork 文档对我来说就像是 broski 吗？...

步骤

• 我创建了一个主 forkRepository 函数，它是执行 fork 功能的主要入口点 - 它引导其他地方
• 我添加了以下函数，这些函数主要用作明显的主 forkRepository 函数的帮助程序
  • isRepositoryForked - 此函数检查 jargons.dev 存储库是否已分叉到当前经过身份验证的用户帐户
  • isRepositoryForkUpdated - 检查分叉（如果找到）是否（与头存储库同步）与主 jargons.dev 存储库是最新的
  • updateRepositoryFork - 用于更新（同步）存储库到主（头）jargons.dev 存储库的状态
  • getBranch - 是一个基本实用程序（在编写此脚本时需要），用于获取 jargons.dev 存储库和用户分支的分支/引用详细信息，以在 isRepositoryForkUpdated 帮助程序中完成的比较中使用以执行其主要功能；它使用 GitHub References 端点。

我的奇怪假设

在我脑海中闪过？当我写这个脚本时，我在阅读了 GitHub Fork 文档中下面引用的段落后一直坚持这个想法

注意：分叉存储库是异步发生的。您可能需要等待一小段时间才能访问 git 对象。如果这花费的时间超过 5 分钟，请务必联系 GitHub 支持。

我误解了这一点，并假设我们只能启动一个分叉过程，继续前进，并且肯定无法等待返回新分叉详细信息的响应对象，因为我们不知道当 fork 进程完成时。

这个假设迫使我不从主 forkRepository 函数返回任何数据，此时我已经开始思考 - 我如何获取分叉详细信息以处理贡献过程的下一阶段！？嗯，也许我会使用网络钩子？！？

事实证明我想得太多了？，我后来意识到我实际上会得到分叉的响应详细信息，这导致我做了一个后续 PR 来解决从分叉响应对象返回所需的数据以供消费贡献过程。

公关

主要的：

壮举：实现 `fork` 存储库脚本 #3

巴布尔贝 发布于 2023 年 12 月 31 日

这个 Pull Request 实现了 fork 脚本；该脚本旨在用于以编程方式将主项目存储库分叉到用户帐户；它包含一个主要函数和其他辅助函数，用于执行一些必要的操作，以确保高效的回购分叉操作。

所做的更改

• 在脚本中实现了主要的 forkRepository 功能；该函数是执行主要 fork 操作的主要导出函数；它接受 userOctokit （一个经过用户身份验证的对象，有权代表用户行事）实例和项目的存储库详细信息，即 repoDetails 对象，并且它执行以下操作...
  • 它使用 isRepositoryForked 辅助函数检查项目存储库是否已分叉到用户帐户；这将返回 null 的分叉
    • 如果存储库已经分叉，那么我们使用 isRepositoryForkUpdated 辅助函数检查分叉是否是最新的/与主项目存储库同步；这将返回 UpdatedSHA 和一个布尔值 isUpdated 属性，用于确认 fork 是否是最新的
      • 如果 fork 不是最新的；然后我们使用 updateRepositoryFork 辅助函数将其与主项目存储库同步来执行更新
    • 如果存储库是最新的/与主项目存储库同步；我们此时取消操作并提前返回；
  • 如果项目存储库未分叉到用户帐户上；然后我们通过使用 userOctokit 实例调用“POST /repos/{owner}/{repo}/forks”端点来启动 fork 进程。 （这将启动分叉过程，我们不知道该过程何时完成？）
• 实现在主 forkRepository 函数和其他辅助函数中使用的以下辅助函数
  • updateRepositoryFork - 用于将存储库更新（同步）到主（头）存储库的状态
  • isRepositoryForkUpdated - 用于检查分叉是否（与头存储库同步）与主存储库是最新的
  • getBranch - 用于获取分支/参考详细信息
  • isRepositoryForked - 用于检查用户的分叉存储库列表中是否存在特定存储库
• 将 getRepoParts 添加到 /lib/utils；它是一个实用程序函数，用于从存储库全名解析 repoOwner 和 repoName。

相关问题

解决#2

截屏/屏幕截图

https://github.com/babblebey/jargons.dev/assets/25631971/16221b7e-3c28-4c6c-a1f3-24d583ce7e3a

？

在 GitHub 上查看

壮举：在 fork 脚本中返回 repo `fullname` #29

巴布尔贝 发表于 2024 年 4 月 4 日

此 PR 是对 #3 中 fork 脚本初始实现中缺失步骤的后续操作； fork 脚本无法返回可用于下一步计算的存储库。这是因为我在最初实施期间有一个奇怪的假设。 ？请参阅下面我的假设...

我假设对“POST /repos/{owner}/{repo}/forks”端点的调用只能确保启动分叉过程，而根本无法保证我们得到响应。这意味着我们可能无法在调用

之后准确获得response.data

...但事实并非如此，我发现response.data确实出现了，但可能只需要一些时间，而且只有在分叉的回购协议很大的情况下......而目前分叉项目仓库的时间不到 5 秒。

所做的更改

• 返回的 fork 存储库 - 这是从 isRepositoryForked 辅助函数返回的存储库全名值；我特此将其作为 forkRepository 函数执行的主要返回值返回，前提是存储库已在执行用户的帐户上分叉
• 返回的response.data.full_name - 这是一个新创建的fork repo fullname；它是对“POST /repos/{owner}/{repo}/forks”端点调用的响应的值；在执行用户帐户上尚未找到分叉的情况下，我特此将其作为 forkRepository 函数执行的主要返回值返回
• Cherry 从 #25 中选择了一些更改用于此处
  • f12f25f548a5c5836e9be7d601ed226c5269f5ee
  • 436ceea649b67812c0ec1164fde95d443ce556e0

？

在 GitHub 上查看