Git - 分散式工作流

---

---

分散式工作流

Git 的分散式架構允許比集中式版本控制系統 (CVCS) 更靈活的協作。

• Git 中的每個開發人員都既是潛在的中心節點，也是節點本身。

• 透過各種可用的工作流選項，開發人員可以維護自己的公共儲存庫併為其他人的儲存庫做出貢獻。

• 我們將深入瞭解一些流行的分散式工作流概念。

• 它提請注意它們的優點、缺點以及結合來自多個角度的元素的能力。

分散式工作流的優勢

分散式工作流有很多優勢，例如

• 協作 - 主要優勢之一是，當多個貢獻者或開發人員可以一起在一個儲存庫上工作時，不會影響彼此的工作。

• 靈活性 - 可以靈活地選擇適合其團隊結構和專案的工作流型別。

• 離線 - 對於遠端和分散式團隊，它使開發人員更容易離線工作，然後稍後同步他們的更改。

• 試用 - 使用分散式工作流，開發人員可以嘗試和試驗他們的想法，而無需更改主程式碼或基礎程式碼。

工作流型別

集中式工作流

在集中式工作流系統中，中央儲存庫充當單個協作模型的中心焦點。

開發人員程式碼貢獻的中心點是這個主儲存庫。

• 每個人都使用這個中央儲存庫來保持其工作的同步。

• 開發人員利用這個中央位置作為節點來使用和同步其更新。

• 如果兩個開發人員從中央儲存庫克隆並都進行更改，則由於集中式工作流，第一個開發人員可以輕鬆地將其更改傳送回。

• 但是，在推送他們所做的更改之前，第二個開發人員必須將其更改合併到自己的工作中。

• 透過這樣做，他們可以確保不會覆蓋第一個開發人員的工作。

Git 有效地支援此模型，並且此理念在 Subversion 和 Git 等版本控制系統中是一致的。

如果我們的團隊習慣於集中式工作流，則切換到 Git 很簡單。

建立一個單一的儲存庫，併為每個團隊成員提供推送訪問許可權。

透過防止使用者覆蓋彼此的工作，Git 保留了可識別的集中式工作流結構。

• 開發人員 1 和開發人員 2 同時開始工作。完成工作後，開發人員 1 將更新推送到伺服器。

• 開發人員 2 嘗試推送她的更改，但伺服器拒絕了它，因為更改與快速轉發不相容。

• 為了正確推送她自己的更改，開發人員 2 必須首先獲取併合並最新的更改。

• 此工作流的便捷性和熟悉性使其廣受歡迎。

• Git 的分支方法使其能夠很好地擴充套件到小型團隊之外。

• 使用 Git，數百名工程師可以一起在一個專案上工作，並輕鬆管理多個分支。

整合管理器工作流

Git 的適應性允許在協作工作流中使用多個遠端儲存庫。

通常，每個開發人員都對其他開發人員的公共儲存庫具有讀取訪問許可權，並對其自己的儲存庫具有寫入訪問許可權。

• 專案的權威來源是規範儲存庫。

• 開發人員可以透過克隆專案、編輯他們自己的公共克隆並推送更新版本來做出貢獻。

• 之後，主專案的維護者會收到開發人員的拉取請求。

• 維護者審查、測試併合並更改後，更改將被推回主儲存庫。

• 這種分散的過程允許協作開發，同時保持對專案的完整性控制。

流程如下

• 專案維護者將更新推送到公共儲存庫。

• 貢獻者克隆維護者的儲存庫並新增更改。

• 貢獻者將其更新版本上傳到一個公共可訪問的儲存庫。

• 透過電子郵件，貢獻者請求維護者拉取更改。

• 維護者將貢獻者的儲存庫新增為遠端，並在本地合併更改。

• 然後，維護者將合併的更改推送到主儲存庫。

• 此過程簡化了協作和對貢獻的受監管整合。

這是 GitLab 或 GitHub 等平臺的標準流程。

• 貢獻者可以透過為專案建立分支來將更新發布到他們自己的公共分支儲存庫。

• 貢獻者能夠獨立地在其分支上工作是一個主要優勢。

• 主儲存庫維護者可以在方便的時候合併來自分支的更改。

  由於這種靈活性，貢獻者不必等待專案的計劃發生變化以反映他們的改進。

獨裁者和副官工作流

多個儲存庫由副官監督，副官是整合管理員。

Linux 核心等專案是此過程的良好示例。

• 一個稱為仁慈獨裁者的中央權威受到副官的監督，副官負責專案的特定方面。

• 仁慈獨裁者從其目錄中收集更新並將其移動到參考檔案。

• 之後，每個協作者都從這個參考儲存庫中拉取更新。

• 此方法確保在整個開發過程中進行集中控制和同步。

• 定期開發人員在其自己的主題分支上工作，他們經常將工作重新設定到參考儲存庫的主分支上。

• 將開發人員的主題分支合併到他們自己的主分支的任務屬於副官。

• 獨裁者將副官的主分支合併到一個主分支中。

• 最後，獨裁者透過將其主分支推送到參考儲存庫來確保所有其他開發人員都可以重新設定其工作到此更新的主分支上。

雖然不常見，但此方法在分層環境或大型專案中具有優勢。

它允許專案經理（獨裁者）為副官分配重要任務。

副官在分支整合之前收集重要程式碼子集的不同時間點。

功能分支工作流

此工作流的核心思想是所有功能開發都應在專用分支中進行，而不是在主分支或 master 分支中進行。這會導致主分支在任何時候都擁有正確的程式碼，而不是錯誤的程式碼。

• 每個新的修復或功能都將在其自己的分支中開發，而不是主分支。

• 完成功能後，可以透過拉取請求將其合併到主分支中。

• 此方法使管理更改和審查程式碼變得更容易，因為新的修復或功能與主基礎程式碼隔離。

Gitflow 工作流

Gitflow 工作流涉及功能分支和許多主分支。它具有許多生命週期較長的分支和較大的提交。它是一種更結構化的方法，並且包含各種分支型別

• 主用於生產就緒程式碼。

• 開發用於需要整合的功能。

• 功能分支用於要合併的新功能。

• 釋出分支用於生產中的新版本。

• 修補程式分支用於程式碼中的緊急修復。

Gitflow 為開發和釋出提供了非常清晰和組織良好的路徑。

Forking 工作流

Forking 工作流為每個開發人員或貢獻者提供他們自己的伺服器端儲存庫，而不是使用單個伺服器端儲存庫。

這意味著每個貢獻者都有兩個 Git 倉庫，一個是私有的本地倉庫，另一個是公開的伺服器端倉庫。

• 它通常用於公共開源專案。

• 貢獻者分叉中央倉庫以建立他們自己的副本。

• 開發者可以更改他們分叉的副本並向原始倉庫提交拉取請求以供審查。

• 這是一種簡單有效的方法，允許任何人進行貢獻，而無需直接干擾主倉庫的程式碼。

分叉倉庫或分叉不是 Git 中任何特殊或不同的命令。分叉的倉庫是使用標準的git clone命令建立的。這些倉庫是伺服器端克隆，通常由第三方 Git 服務提供商管理，例如 GitHub、BitBucket 等。

拉取請求工作流

拉取請求工作流是一種輕量級方法，它基於分支型工作流。

團隊使用拉取請求來提出更改、討論和審查程式碼更改，然後再合併。它通常與功能分支或分叉工作流結合使用，以實現有效的審查和程式碼協作。

以下是此工作流的步驟

• 1. 將更改拉取到您的本地倉庫以獲取最新的基礎。現在建立一個分支。

• 2. 將更改提交到此新分支。

• 3. 將您的更改推送到新分支。

• 4. 開啟一個拉取請求來提出更改。

• 5. 討論和審查程式碼。

• 6. 對程式碼進行變基並測試它。

• 7. 最後，將您的分支合併到主分支。

主幹開發工作流

在主幹開發模型中，與 Gitflow 的長期分支相比，開發人員建立了具有少量小提交的短期分支。

• 開發人員直接在主分支或主幹分支上工作。

• 更改會頻繁整合。

• 最大限度地減少了長期分支和大型提交的使用。

• 這種方法強調更持續的整合。

每個工作流都有其自身的優勢，應根據專案的需要和團隊的偏好進行選擇。因為所有不同的工作流都使團隊能夠利用 Git 強大的分支和合並功能進行協作。