這是我按照系統架構中所述編寫的 4 個腳本中的第一個。感覺很抽氣！這是朝著創建「wiki」體驗方向邁出的一步，無需與 GitHub UI 互動即可為開源做出貢獻？ 。
這些腳本是什麼？
這些 js 檔案包含一些相關的可重複使用函數，特別是用於與 GitHub API 互動；它們要么在同一腳本中使用，要么導出以用於在專案中的其他地方執行其基本功能。它們接受經過身份驗證的使用者 Octokit 實例作為其他人的參數，該實例用於代表經過身份驗證的使用者透過 GitHub API 執行操作/功能。
需要建立一個在不與GitHub UI 互動的情況下為開源做出貢獻的流程，這意味著我們必須自動化一些流程- 模擬使用者透過GitHub UI 做出貢獻時將採取的每個步驟，步驟如下如下..
- 分叉專案倉庫
- 建立分支
- 提交對分支的變更（在 src/pages/word/ 目錄中新增新的 mdx 檔案以取得新單字或編輯現有的文件，在我們的例子中）
- 建立拉取請求（在我們的例子中提交單字更改）
一個值得陳述的真理
我在初次提交後就開始編寫這個腳本，這實際上是 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 存儲庫和用戶分支的Branch/Ref 詳細信息，以在isRepositoryForkUpdated 幫助程序中完成的比較中使用以執行其主要功能；它使用GitHub 參考端點。
我的奇怪假設
在我腦海中閃過？當我寫這個腳本時，我在閱讀了下面引用的 GitHub Fork 文件中的段落後仍然堅持這個想法
注意：分叉儲存庫是非同步發生的。您可能需要等待一小段時間才能存取 git 物件。如果這需要超過 5 分鐘，請務必聯絡 GitHub 支援。
我誤解了這一點，並認為我們只能啟動一個分叉進程，然後繼續，並且肯定無法等待返回新分叉詳細信息的響應對象，因為我們不知道當 fork 進程完成時。
這個假設迫使我不從主 forkRepository 函數返回任何數據，此時我已經開始思考 - 我如何獲取分叉詳細信息以處理貢獻過程的下一階段！ ？嗯，也許我會使用網路鉤子？ ！ ？
原來我想太多了？ ，後來我意識到我實際上會得到分叉的響應詳細信息，這導致我做了一個後續 PR 來解決從分叉響應對象返回所需的數據以供消費貢獻過程。
公關
主要：
壯舉：實作 `fork` 儲存庫腳本
#3
這個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
此 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 上查看
以上是建置 jargons.dev [# Fork 腳本的詳細內容。更多資訊請關注PHP中文網其他相關文章！
