Git是最流行的代碼版本控制系統(tǒng)，這一系列文章介紹了一些Git的高階使用方式，從而幫助我們可以更好的利用Git的能力。本系列一共8篇文章，這是第2篇。原文：Branching Strategies in Git[1]
幾乎所有的版本控制系統(tǒng)(VCS)都有某種類型的分支支持。簡而言之，分支意味著可以創(chuàng)建一個新的、獨立的容器而離開主開發(fā)線，并繼續(xù)在那里工作。通過這種方式，可以在不破壞生產代碼庫的情況下進行試驗和嘗試。Git用戶知道Git的分支模型非常特殊，而且非常強大，這是Git最酷的功能之一。Git的分支模型快速且輕量，在分支之間來回切換的速度與創(chuàng)建或刪除分支一樣快?？梢哉fGit鼓勵使用大量分支和合并的工作流。
Git把創(chuàng)建多少分支以及合并的頻率完全交給了開發(fā)者決定。如果你獨自編寫代碼，可以自由選擇什么時候創(chuàng)建新分支，以及保留多少個分支。但當我們在團隊中工作時，情況就不同了。Git提供工具，但是團隊需要負責以最佳方式使用這一工具！
本文將討論分支策略和不同類型的Git分支，還會介紹兩種常見的分支工作流: Git Flow和GitHub Flow。
Git進階系列:
團隊合作: 制定規(guī)則
在探索構建發(fā)布和集成變更的不同方法之前，先來討論一下規(guī)則。如果在團隊中工作，需要對項目的通用工作流和分支策略達成一致，最好將其寫下來，讓所有團隊成員都能看到。
誠然，并不是每個人都喜歡編寫文檔或指導方針，但將最佳實踐記錄在案不僅可以避免錯誤和沖突，還有助于培訓新團隊成員。解釋分支策略的文檔將幫助他們理解團隊是如何工作的，以及如何處理軟件版本。
以下是我們自己文檔中的一些例子:
-
master代表當前的公開發(fā)布分支 -
next表示下一個公開發(fā)布分支(這樣我們就可以在master上提交修補程序而不會引入不必要的更改) - 特性分支被分組在
feature/下 - WIP分支被分組在
wip/下(可以用來創(chuàng)建個人WIP的“備份”)
不同團隊可能對這些規(guī)則有不同看法(例如“wip”或“feature”組)，這肯定會反映在他們自己的文檔中。
集成變更和結構化發(fā)布
當我們考慮如何在Git倉庫中使用分支時，應該從考慮如何集成變更和如何構建發(fā)布開始。所有這些話題都是緊密相連的，為了更好的理解不同的選擇，我們來看下兩種不同的策略。下面的例子是為了說明極端情況會怎么樣，從而幫助你思考如何設計自己的分支工作流:
- 主線開發(fā)
- 狀態(tài)分支、發(fā)布分支和特性分支
第一個選擇可以被描述為“始終集成”，基本上可以歸結為: 始終將自己的工作與團隊的工作集成在一起。在第二種策略中，收集自己的工作并發(fā)布，即多個不同類型的分支進入預發(fā)階段。兩種方法各有利弊，兩種策略都適用于某些團隊，但不適用于另一些團隊，大多數開發(fā)團隊在這兩個極端之間工作。
我們從主線開發(fā)開始解釋這個策略是如何工作的。
主線開發(fā)
之前提到過，這種方法的座右銘是“總是集成”。只有一個單獨的分支，每個人都在主線上開發(fā):
記住，這是一個簡化的例子，我懷疑在現實世界中是否有任何團隊能夠使用如此簡單的分支結構。然而，理解這個模型的優(yōu)點和缺點確實有幫助。
首先，只有一個分支，因此很容易跟蹤項目中的變化。其次，提交必須相對較小: 在不斷集成到生產代碼的環(huán)境中，不能冒險進行大而臃腫的提交。因此，團隊的測試和QA標準必須是一流的！如果沒有一個高質量的測試環(huán)境，主線開發(fā)方法就不適合。
狀態(tài)分支、發(fā)布分支和特性分支
下面看看另一種情況，如何使用多個不同類型的分支。每個分支都有不同的工作: 新特性和實驗代碼保存在自己的分支中，發(fā)布可以在自己的分支中規(guī)劃和管理，甚至開發(fā)流程中的各種狀態(tài)也可以用分支來表示:
記住，這完全取決于團隊和項目的需求。雖然這種方法一開始可能看起來很復雜，但完全是一個練習和習慣的問題。
現在，讓我們更詳細地探討兩種主要的分支類型: 長期分支(long-running branches)和短期分支(short-lived branches)。
長期分支
每個Git倉庫至少包含一個長期分支，通常稱為master或main。當然，團隊可能會決定在項目中使用其他長期分支，例如類似于開發(fā)(develop)、生產(production)或預發(fā)(staging)分支。所有這些分支都有一個共同點: 存在于整個項目生命周期中。
像master或main這樣的主線分支是長期分支的一個例子。此外，還有所謂的集成分支，如開發(fā)或預發(fā)。這些分支通常代表項目發(fā)布或部署過程中的狀態(tài)。如果代碼在開發(fā)生命周期中經歷了不同的狀態(tài)（例如，從開發(fā)階段到預發(fā)階段再到生產階段），在分支中的這個鏡像結構也是有意義的。
關于長期分支的最后一點: 大多數團隊都有一個類似于“不要直接向長期分支提交內容”的規(guī)則，通常通過merge或rebase來集成。制定這項規(guī)則有兩個主要原因:
- 質量: 不應將未經測試或評審的代碼發(fā)布到生產環(huán)境中。
- 捆綁發(fā)布和調度: 可能希望分批發(fā)布新代碼，甚至提前安排發(fā)布。
接下來是短期分支，通常為特定目的而創(chuàng)建，然后在代碼集成后刪除。
短期分支
與長期分支相反，短期分支是為臨時目的而創(chuàng)建的，一旦它們完成了職責并且代碼被集成到主線(或另一個長期分支)中，就會被刪除。有許多不同的原因需要創(chuàng)建短期分支，例如致力于新的實驗性特性，修復bug，重構代碼，等等。
短期分支通?；陂L期分支創(chuàng)建。假設我們開始有一個新特性的開發(fā)，可以基于長期的主分支創(chuàng)建新特性分支。在若干次提交和測試之后，工作完成，新特性可以集成到主分支中，并且merge或rebase之后，可以刪除特性分支。
兩種流行的分支策略
最后我們看一下兩種流行的分支策略: Git Flow和GitHub Flow。雖然不同的團隊可能會決定完全不同的分支策略，但這兩種流行的策略可以作為團隊分支策略的靈感來源。
Git Flow
Git Flow[2]是一個著名的分支策略，其中main分支總是反映當前的生產狀態(tài)，此外還有第二個長期分支，通常稱為develop。所有特性分支都從這里創(chuàng)建，并將合并到develop中。而且，該分支是新發(fā)布的起點: 開發(fā)人員創(chuàng)建一個新的release分支，在上面工作、測試、提交bug修復。一旦一切正常，并且確信已經準備好投入生產，就將它合并回main。作為最后一步，在main上為發(fā)布添加一個標簽，并刪除release分支。
Git Flow對于可打包的軟件(桌面)應用程序或庫來說工作得很好，但對于網站項目來說似乎有點過頭了。在這類項目里，main分支和release分支之間通常區(qū)別不大，分不同的分支沒有特別大的好處。
如果使用的是像Tower這樣的Git桌面GUI，可以在界面中找到可能的操作，不需要記住任何新命令:
GitHub Flow
如果團隊遵循短生產周期和頻繁發(fā)布的持續(xù)交付方式，建議看看GitHub Flow[3]。
這種方式非常精益和簡單: 有一個長期分支，即默認的main分支，任何正在做的工作都有自己獨立的分支，無所謂是新特性、bug修復還是重構。
“最好”的Git分支策略是什么?
如果問10個不同的團隊他們是如何使用Git分支的，可能會得到10個不同的答案。沒有所謂的“最佳”分支策略，也沒有每個人都應該采用的完美工作流。為了找到最適合團隊的模型，應該坐下來分析所做的項目，討論發(fā)布策略，然后決定一個分支工作流，從而以最好的方式支持我們的項目。
如果想更深入了解高級Git工具，可以免費查看“Advanced Git Kit[3]”: 這是關于分支策略、交互式Rebase、Reflog、子模塊等主題的短視頻集合。
References:
[1] Branching Strategies in Git: https://css-tricks.com/branching-strategies-in-git/
[2] A Successful Git Branching Model: http://nvie.com/posts/a-successful-git-branching-model/
[3] GitHub Flow: https://guides.github.com/introduction/flow/
你好，我是俞凡，在Motorola做過研發(fā)，現在在Mavenir做技術工作，對通信、網絡、后端架構、云原生、DevOps、CICD、區(qū)塊鏈、AI等技術始終保持著濃厚的興趣，平時喜歡閱讀、思考，相信持續(xù)學習、終身成長，歡迎一起交流學習。
微信公眾號：DeepNoMind
