沒有混亂的團隊合作：理解 Git 中的分支策略

介紹

Git 已成為軟件開發中版本控制系統事實上的行業標準。您應該首先閱讀我關於 Git 是什麼以及如何開始的文章。你讀過嗎？太好了，我們出發吧！不管喜歡與否，這個由 Linus Tovalds 創建的工具不會退休。因此，討論分佈式團隊如何使用 Git 以及他們應該為此選擇什麼樣的分支策略是有意義的。這不是一個無關緊要的問題。當組建一個以前沒有合作過的新開發團隊時，分支策略通常是首先要決定的事情之一。而有些人會口吐白沫來證明一種策略比另一種策略更好。因此，我想向您傳達一些關於它們的一般信息。

分支策略是否必要？

它們確實是必要的。非常有必要。因為如果團隊不同意某事，那麼每個團隊成員都會做他或她想做的事：

• 在任何分支機構工作
• 合併到任意其他分支
• 刪除一些分支
• 創造新的
• 因此每個團隊成員都將在不受管理的流程中行動。

這就是為什麼我們要考慮以下三種策略。我們走吧！

GitHub 流程

奇怪的是，這種分支策略在 GitHub 上是首選 :) 它帶有一組規則：

1. 主分支中的代碼不能被破壞。它應該隨時準備好部署。也就是說，您不得將阻止您構建項目並將其部署到服務器的代碼放在那裡。
2. 當你打算開發新的功能時，你需要在 master 分支的基礎上創建一個新的特性分支，並給它起一個有意義的名字。在本地提交代碼並定期將更改推送到遠程存儲庫中的同一分支。
3. 當您認為工作已經準備好並且可以合併到 master 分支中時（或者如果您不確定，但想獲得對已完成工作的反饋），打開一個拉取請求（您可以在此處閱讀有關拉取請求的信息）。
4. pull request 中的新特性通過審核後，就可以合併到 master 分支中了。
5. 當更改合併到 master 分支時，它們應該立即部署到服務器。

根據 GitHub Flow 的說法，在開始處理新事物之前，無論是修復還是新功能，您都需要基於 master 創建一個新分支並為其命名。接下來，開始實施工作。您應該不斷地向具有相同名稱的遠程服務器提交提交。當您斷定一切就緒時，您需要向 master 分支創建一個拉取請求。然後至少有一個人，或者更好的是，兩個人應該在單擊“批准”之前查看此代碼。通常，項目的團隊負責人和第二個人絕對應該看一看。然後就可以完成pull request了。GitHub Flow 還以推動項目中的持續交付 (CD)而聞名。這是因為當更改進入 master 分支時，它們應該立即部署到服務器。

GitFlow

之前的策略 (GitHub Flow) 的核心並不是很複雜。有兩種類型的分支：主分支和功能分支。但 GitFlow 更嚴重。至少，上面的圖片應該清楚了:)那麼這個策略是如何工作的呢？一般來說，GitFlow 由兩個持久分支和幾種臨時分支組成。在 GitHub Flow 的上下文中，主分支是持久的，其他分支是臨時的。 持久分支

• 主人：任何人都不應該觸摸或推動任何東西到這個分支。在這個策略中，master代表最新的穩定版本，用於生產（也就是在真實服務器上）
• 開發：開發分支。它可能不穩定。

使用三個輔助臨時分支進行開發：

1. 功能分支——用於開發新功能。
2. 發布分支——用於準備發布新版本的項目。
3. Hotfix 分支——用於快速修復真實用戶在真實服務器上發現的錯誤。

特色分支

功能分支是由開發人員為新功能創建的。它們應該始終基於開發分支創建。完成新功能的工作後，您需要向開發分支創建拉取請求。顯然，大型團隊可以同時擁有多個功能分支。再看一下GitFlow策略描述開頭的那張圖。

發布分支

當所需的新功能集在開發分支中準備就緒時，您就可以準備發布新版本的產品了。基於開發分支創建的發布分支將幫助我們實現這一點。使用發布分支時，您需要查找並修復所有錯誤。穩定發布分支所需的任何新更改也必須合併回開發分支。這樣做也是為了穩定開發分支。當測試人員說該分支對於新版本來說足夠穩定時，它就會被合併到 master 分支中。稍後為該提交創建一個分配有版本號的標籤。要查看示例，請查看策略開頭的圖片。在那裡你會看到標籤 1.0— 這只是一個表示項目 1.0 版本的標籤。最後，我們有 hotfix 分支。

修補程序分支

Hotfix 分支還用於向 master 分支發布新版本。唯一的區別是這些版本不是計劃中的。在某些情況下，錯誤會進入已發布的版本並在生產環境中被發現。以 iOS 為例：新版本發布後，您會立即獲得大量更新，其中修復了發布後發現的錯誤。因此，我們需要快速修復錯誤並發布新版本。在我們的圖片中，這對應於版本 1.0.1。這個想法是，當需要修復真實服務器上的錯誤時（或者我們所說的“在生產中”或“在生產中”），新功能的工作不必停止。hotfix 分支應該從 master 分支創建，因為它代表當前在生產中運行的內容。一旦錯誤修復準備就緒，它被合併到 master 中，並創建了一個新標籤。就像準備發布分支一樣，修補程序分支也應該將其修復合併回開發分支。

分叉工作流程

在分叉工作流程中，開發涉及兩個存儲庫：

1. 原始存儲庫，所有更改都將合併到其中。
2. 一個分支存儲庫。這是原始存儲庫的副本，由另一個想要對原始存儲庫進行更改的開發人員擁有。

到目前為止聽起來有點奇怪，對吧？任何接觸過開源開發的人都已經熟悉這種方法。這種策略具有以下優勢：可以在分支存儲庫中進行開發，而無需授予在原始分支中進行聯合開發的權限。當然，原始存儲庫的所有者有權拒絕提議的更改。或者接受並合併它們。這對於原始存儲庫的所有者和想要幫助創建產品的開發人員來說都很方便。例如，您可以建議對Linux 內核進行更改。如果 Linus 認為它們有意義，將添加更改 (!!!)。

分叉工作流程的示例

當有要使用的庫時，將在 GitHub 上應用分叉工作流。它有一個錯誤，使您無法完全使用它。假設您足夠深入地研究問題並知道解決方案。使用分叉工作流程，您可以在沒有權限在圖書館的原始存儲庫中工作的情況下解決問題。要開始，您需要選擇一些存儲庫，例如Spring Framework。找到並點擊右上角的“Fork”按鈕：這需要一些時間。然後原始存儲庫的副本將出現在您的個人帳戶中，這將表明它是一個分支：現在您可以像往常一樣使用這個存儲庫，將更改添加到 master 分支，當一切準備就緒後，您可以創建對原始存儲庫的拉取請求。為此，請單擊新建拉取請求按鈕：

選擇哪種策略

Git 是一種靈活而強大的工具，可讓您使用各種流程和策略進行工作。但是你的選擇越多，就越難決定選擇哪種策略。很明顯，每個人都沒有單一的答案。一切都視情況而定。也就是說，有幾條準則可以幫助解決這個問題：

1. 最好先選擇最簡單的策略。僅在需要時才轉向更複雜的策略。
2. 考慮為開發人員提供盡可能少的分支類型的策略。
3. 查看各種策略的優缺點，然後選擇您的項目所需的策略。

關於 Git 中的分支策略，我想說的就是這些。感謝您的關注 :) 在 GitHub 上關注我，我經常在這裡發布涉及我在工作中使用的不同技術和工具的創作。