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

介紹

Git 已成為軟體創建中版本控制事實上的業界標準。要了解 git 是什麼以及如何開始，請先閱讀我關於它的文章。你讀過嗎？太好了，讓我們繼續吧！ 不管你喜歡與否，Linus Towalds 創造的工具不會退休。因此，討論分散式團隊如何在 git 中工作以及為此選擇什麼分支策略是有意義的。這根本不是一個無聊的問題。通常，在組建一個由彼此不合作的新開發人員團隊組成的情況下，分支策略是首先需要決定的事情之一。而且會有人會口吐白沫來證明一種策略比另一種策略好。因此，我想向您傳達有關它們的一般訊息。

是否需要分支策略？

但它們是需要的，而且仍然是需要的。因為如果你不同意團隊中的某些事情，結果每個人都會做他們想做的事：

• 在他想要的部門工作；
• 合併到他想要的其他分支；
• 刪除一些分支；
• 創造新的；
• 等等——每個團隊成員都處於不受控制的流動中。

因此，以下是三種策略。去！

GitHub Flow 策略

分支策略，無論多麼奇怪，在 GitHub 中都是首選:) 附加的是一組需要遵循的 規則：

1. master 分支中的程式碼必須完整無缺並準備好隨時部署（也就是說，您不能將阻止您建置專案並將其部署到伺服器上的程式碼放在那裡）。
2. 當您計劃開發新功能時，您需要基於 master 分支建立一個新分支（功能分支）並為其指定一個有意義的名稱。在本地提交程式碼並定期將變更推送到遠端儲存庫中的相同分支。
3. 當明顯感覺到工作已經準備好並且可以合併到 master 分支時（或者如果您不確定，但想要獲得反饋），請在此處打開 Pull-Request（您可以
4. 拉取請求中的新功能獲得批准後，可以將其合併到主分支。
5. 當變更合併到主分支時，需要立即將它們部署到伺服器。

根據 GitHub Flow 的說法，事實證明，在開始開發新內容之前，無論是修復還是新功能，您需要基於 master 建立新分支並為其指定合適的名稱。接下來，開始實施工作。您需要不斷地將提交推送到具有相同名稱的遠端伺服器。當您了解一切準備就緒後，您需要在 master 分支中建立拉取請求。然後，至少應該由一個人（最好是兩個人）查看此代碼並單擊“批准”。通常，專案的團隊領導和其他人必須查看它，然後您才能完成拉取請求。GitHub Flow 也因推動專案的持續交付 (CD)而聞名。因為當對 master 分支進行更改時，必須立即部署到伺服器上。

GitFlow 策略

之前的策略（GitHub Flow）本質上並不是很複雜。有兩種類型的分支：主分支和功能分支。但GitFlow更嚴重。至少從上圖你可以明白這一點）那麼，這個策略是如何運作的呢？一般來說，GitFlow 由兩個永久分支和幾種類型的臨時分支組成（在 GitHub Flow 的上下文中，master 分支是永久分支，其他分支是臨時分支）。 常設分公司：

• 主人：任何人都不能碰這個樹枝或往那裡推任何東西。在此策略中，master 顯示生產中（即真實伺服器上）所使用的最新穩定版本；
• 發展是發展的分支。它可能不穩定。

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

1. 功能分支 - 用於開發新功能。
2. 發布分支 - 準備發布專案的新版本。
3. 修補程式分支是針對真實使用者在真實伺服器上已發現的缺陷的快速解決方案。

特色分支

功能分支是由開發人員為新功能建立的。它們應該始終基於開發分支。完成新功能的工作後，您需要在開發分支中建立拉取請求。很明顯，在大型團隊中，一次可以有多個功能分支。再次注意GitFlow策略描述開頭的圖片。

發布分支

當開發分支準備好所需數量的新功能後，就可以準備發布產品的新版本了。發布分支將幫助我們做到這一點。它是基於開發分支創建的。在使用發布分支時，您需要尋找並修復所有缺陷。穩定發布分支所需的任何新變更也必須合併回開發中。這樣做是為了穩定和發展分支。當測試人員認為該分支對於新版本來說足夠穩定時，它就會被合併到主分支中。接下來，在此提交上建立一個標籤（標籤：您可以在此處閱讀有關它的更多資訊），並為其分配一個版本號。例如，您可以查看策略開頭的圖片。因此，Tag 1.0 只是一個表示項目版本 1.0 的標籤。最後一件事是分支修補程式。

修補程式分支

修補程式分支也用於在 master 中發布新版本。唯一的區別是此版本尚未計劃。在某些情況下，缺陷已發布並已在生產中發現。例如，iOS：一旦發布新版本，您立即會收到一堆更新，其中修復了發布後發現的缺陷。對此，有必要快速修復這個缺陷並發布新版本。在我們的圖片中，這對應於版本 1.0.1。這個想法是，當您需要修復真實伺服器上的缺陷時，新功能的工作可能不會停止（正如我們所說的“生產中”：再次，英語單字“生產”的副本）。修補程式分支應該從主分支創建，因為它代表生產中的工作狀態。一旦缺陷的解決方案準備就緒，它就會合併到 master 中，並建立​​一個新標籤。就像準備發布分支一樣，修補程式分支應該將其解決方案合併到開發分支中。

分岔工作流程策略

作為分叉工作流程策略的一部分，開發的方式是有兩個儲存庫：

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

到目前為止聽起來有點奇怪，對吧？對於那些已經接觸過開源開發的人來說，這種方法已經很熟悉了。此策略具有以下優點：可以在分叉儲存庫中進行開發，而無需授予原始儲存庫中的聯合開發權限。當然，原始存儲庫的所有者有權拒絕提議的更改。或同意並殺死他們。這對於原始儲存庫的擁有者和想要參與某些產品創建的開發人員來說都很方便。例如，您可以建議對Linux 核心進行變更。如果 Linus 認為它們有意義，則會添加這些更改（！！！）。

分岔工作流程範例

當您想要使用某個函式庫時，可以在 GitHub 上使用 Forking Flow。它有一個缺陷，無法充分利用。假設您已經對問題進行了足夠的研究並知道解決方案。使用分叉工作流程策略，您可以解決此問題，而無需授予在原始庫儲存庫中工作的權限。首先，您需要選擇一個儲存庫，例如Spring Framework core，找到右上角的 Fork 按鈕並點擊它： 這將需要一些時間，之後此原始儲存庫的副本將出現在您的個人帳戶，這將表明它是一個分叉： 然後您可以像往常一樣使用此存儲庫，向主分支添加更改，並在一切準備就緒後，向原始存儲庫創建拉取請求。為此，請按一下「新建拉取請求」按鈕：

選擇哪種策略

Git 是一個靈活且強大的工具，可讓您使用廣泛的流程和策略進行工作。但選擇越大，現在就越難決定要選擇哪一種策略。顯然，沒有一刀切的答案。這一切都取決於具體情況。然而，有一些建議可以幫助解決這個問題：

1. 最好先選擇最簡單的策略。僅在必要時才轉向更複雜的策略。
2. 考慮具有盡可能少類型的開發人員分支的策略。
3. 查看不同策略的利弊，並根據項目選擇合適的策略。

這就是我想告訴你的關於 git 中的分支策略的全部內容。感謝您的關注:) 訂閱我的 GitHub 帳戶，我經常在那裡發布我在工作中使用的各種技術和工具的作品

有用的連結

• GitHub 流程： 使用 Git 和 GitHub 的最佳方式
• 在 GitHub 上拉取請求或如何更改別人的項目
• GitHub：關於拉取請求
• 持續整合、交付和部署的差異化
• Git 基礎：使用標籤
• Habr：Git 的成功分支模型