GitHub 流程的元件

  • 8 分鐘

在此單元中，我們會檢閱下列 GitHub 流程的元件：

  • 分支
  • 認可
  • 提取要求
  • GitHub 流程
  • Git 流程

GitHub Flow 的元件

在進入 GitHub 特定工作流程之前，瞭解 GitHub Flow 會直接建置在 Git 的基本概念上很有説明。

Git 提供了追蹤和管理程式碼隨時間變化的工具。 GitHub 在此基礎上構建，使這些工具更容易使用分支、提交、拉取請求和協作視覺化介面等功能。 讓我們先看看這些概念在 GitHub 中是如何運作的。

什麼是分支

在上一節中，我們在您的存放庫中創建了一個新文件和一個新分支。

分支是 GitHub 體驗中不可或缺的一部分。 它們可讓您進行變更，而不會影響預設分支。

您的分支是實驗新功能或修正程式的安全位置。 如果您犯了錯誤，可以還原變更或推送更多變更來修正錯誤。 在合併分支之前，您的變更不會在預設分支上更新。

注意

或者，您可以建立一個新分支並在終端機中使用 git 將其簽出。 此命令會是 git checkout -b newBranchName

什麼是認可

在上一單元中，您透過推送認可將新檔案新增至存放庫。 讓我們簡短地檢閱什麼是認可。

認可是對分支上一或多個檔案所做的變更。 不論是否透過命令行或直接在 GitHub 的 Web 介面中建立，每個認可都會由唯一標識碼、時間戳和參與者追蹤。 認可會為所有檢閱檔案或連結項目之歷程記錄的人員提供清楚的稽核記錄，例如問題或提取要求。

您可以在終端機中使用 Git 建立提交：

git commit -m "Add a helpful commit message"

主分支的 GitHub 認可清單的螢幕擷取畫面。

在 Git 存放庫中，檔案可以存在於數個有效狀態，因為它會經歷版本控制程序。 Git 存放庫中檔案的主要狀態是未追蹤和已追蹤。

未追蹤：當檔案還不屬於 Git 存放庫時，檔案的初始狀態。 Git 不知道其存在。

已追蹤：已追蹤檔案是 Git 正在主動監視的檔案。 可以處於下列其中一個子狀態：

  • 未修改：會追蹤檔案，但是自從上次認可後尚未修改。
  • 已修改：檔案自從上次認可後已變更，但是這些變更尚未暫存於下一個認可。
  • 已暫存：已修改檔案，並將變更新增至暫存區域 (也稱為索引)。 這些變更已準備好認可。
  • 已認可：檔案位於存放庫的資料庫中。 代表檔案的最新認可版本。

這些狀態可協助您的小組瞭解每個檔案的狀態，以及它在版本控制程式中的位置。

什麼是提取要求？

提取要求是用來發出訊號的機制，其會指出來自某個分支的認可已準備好合併到另一個分支。

提交提取要求的小組成員會要求一或多名檢閱者驗證程式碼，並核准合併。 這些檢閱者有機會對變更加上註解、新增自己的，或使用提取要求本身進行進一步討論。

GitHub 也支援草 稿提取請求，可讓您開啟尚未準備好檢閱的提取請求。

一旦變更已獲核准 (如果需要) 後，提取要求的來源分支 (比較分支) 就會合併到基礎分支。

提取要求和提取要求內註解的螢幕擷取畫面。

現在您已經了解了分支、提交和提取請求的運作方式，讓我們逐步了解它們如何在 GitHub Flow 中組合在一起。

GitHub 流程

螢幕擷取畫面以線性格式顯示 GitHub 流程的視覺化表示法，其中包括新分支、認可、提取要求，以及依該順序將變更合併回 main。

GitHub 流程是一個簡單的工作流程，可協助您安全地進行和共用變更。 它非常適合嘗試想法並使用分支、拉取請求和合併與您的團隊協作。

注意

GitHub 流程是數個熱門工作流程之一。 其他包括 Git 流程和基於主幹的開發。

現在我們知道 GitHub 的基本概念，我們可以逐步執行 GitHub 流程及其元件。

  1. 首先建立分支，讓您的變更、功能或修正不會影響主要分支。
  2. 接下來，在分支中進行更新。 如果您的工作流程支援，您可以從此分支部署變更，以在合併之前進行測試。
  3. 現在，開啟提取請求以邀請回饋並開始審查。
  4. 然後，查看評論並根據團隊的反饋進行必要的更新。
  5. 最後，一旦您對變更有信心，請獲得批准並將提取請求合併到主分支中。
  6. 之後，刪除分支以保持儲存庫乾淨並避免使用過時的分支。

Git 流程

說明 Git 流程工作流程的圖表，其中包含功能分支、開發、發行分支、Hotfix 和主要分支的平行通道。它顯示如何將功能合併到開發中、從開發建立發行分支、從主版分支Hotfix，以及所有變更最終合併回主版和具有標記版本的開發。

雖然 GitHub Flow 是專為持續傳遞而設計的輕量型工作流程， 但 Git 流程 是較結構化的分支模型，通常用於發行驅動環境中。 Git 流程已超過 GitHub Flow，而且您仍會看到使用的詞彙 master ，而不是 main 預設分支。

Git 流程分支類型

Git 流程使用數個長期且暫時的分支：

  • master：一律反映生產就緒的程序代碼。
  • develop：包含下一個版本的最新開發工作。
  • feature/*：用於創建新功能;分支並在 develop 完成後合併回來。
  • release/*：準備新的生產版本 develop，允許進行最終測試和次要錯誤修正。
  • hotfix/*：用於快速修補生產問題;分支自 master。

Git 流程流程的運作方式

  1. 開發人員會從中develop建立功能分支，以建置新功能。
  2. 當需要發行時，會從 建立develop發行分支。 這隔離了發行準備工作，以便開發可以不間斷地繼續進行。
  3. 錯誤修正可以新增至發行分支，但主要功能應等待未來的發行。
  4. 準備就緒後，發行分支會合併到版本號碼中 master 並標記版本號碼。 GitHub 可以使用這些標籤來協助您產生版本資訊。
  5. 應該將相同的發行分支合併回， develop 以保持同步。
  6. 如果發生重大生產錯誤，則會從 master建立 Hotfix 分支。 修正之後，它會合併至 master 和 develop。

使用 Git 流程的時機

  • 最適合具有 排程或版本設定版本的專案
  • 如果您維護 多個生產版本 （例如長期支援分支），則很有説明。
  • 適用於 較慢、更結構化的開發週期 （例如企業或受管制的環境）
  • 由於額外的分支管理，被認為比 GitHub Flow 更「重量級」

注意

Git 流程假設合併提交以整合分支。 使用變基或壓縮合併可能會干擾其分支結構和歷史記錄追蹤。

對於許多使用 GitHub 的團隊來說，GitHub Flow 更簡單、更快速。 但是，如果您的小組重視可預測性，而且需要更多發行規劃，Git 流程可能更適合。

祝賀！ 您剛剛逐步解說完整的 GitHub Flow，並探索 Git 流程如何提供發行驅動項目的結構化替代方案。

讓我們移至下一節，我們將會討論問題和討論之間的差異。