Git是目前最流行的源代碼管理工具。大量的軟件項目由GitHub、Bitbucket和GitLab這樣的云服務(wù)平臺或是私有的Git倉庫來管理。在使用Git時通常會遇到的一個問題是采用何種分支管理實踐，即如何管理倉庫中作用不同的各類分支。和軟件開發(fā)中的其他實踐一樣，Git分支管理并沒有普遍適用的最佳做法，而只有對每個團隊和項目而言最適合的做法。簡單來說，在項目開發(fā)中使用多個分支會帶來額外的管理和維護開銷，但是多個分支對于項目的團隊合作、新功能開發(fā)和發(fā)布管理都是有一定好處的。不同的團隊可以根據(jù)團隊人員組成和意愿、項目的發(fā)布周期等因素選擇最適合的策略，找到最適合團隊的管理方式。這里講一下三種常見的Git分支管理方式。
單主干的分支實踐（Trunk-baseddevelopment，TBD）在SVN中比較流行。Google和Facebook都使用這種方式。trunk是SVN中主干分支的名稱，對應(yīng)到Git中則是master分支。TBD的特點是所有團隊成員都在單個主干分支上進行開發(fā)。當需要發(fā)布時，先考慮使用標簽（tag），即tag某個commit來作為發(fā)布的版本。如果僅靠tag不能滿足要求，則從主干分支創(chuàng)建發(fā)布分支。bug修復(fù)在主干分支中進行，再cherry-pick到發(fā)布分支。圖1是TBD中分支流程的示意圖。
圖1.TBD中的分支流程的示意圖
由于所有開發(fā)人員都在同一個分支上工作，團隊需要合理的分工和充分的溝通來保證不同開發(fā)人員的代碼盡可能少的發(fā)生沖突。持續(xù)集成和自動化測試是必要的，用來及時發(fā)現(xiàn)主干分支中的bug。因為主干分支是所有開發(fā)人員公用的，一個開發(fā)人員引入的bug可能對其他很多人造成影響。不過好處是由于分支所帶來的額外開銷非常小。開發(fā)人員不需要頻繁在不同的分支之間切換。
GitHubflow是GitHub所使用的一種簡單的流程。該流程只使用兩類分支，并依托于GitHub的pullrequest功能。在GitHubflow中，master分支中包含穩(wěn)定的代碼。該分支已經(jīng)或即將被部署到生產(chǎn)環(huán)境。master分支的作用是提供一個穩(wěn)定可靠的代碼基礎(chǔ)。任何開發(fā)人員都不允許把未測試或未審查的代碼直接提交到master分支。
對代碼的任何修改，包括bug修復(fù)、hotfix、新功能開發(fā)等都在單獨的分支中進行。不管是一行代碼的小改動，還是需要幾個星期開發(fā)的新功能，都采用同樣的方式來管理。當需要進行修改時，從master分支創(chuàng)建一個新的分支。新分支的名稱應(yīng)該簡單清晰地描述該分支的作用。所有相關(guān)的代碼修改都在新分支中進行。開發(fā)人員可以自由地提交代碼和push到遠程倉庫。
當新分支中的代碼全部完成之后，通過GitHub提交一個新的pullrequest。團隊中的其他人員會對代碼進行審查，提出相關(guān)的修改意見。由持續(xù)集成服務(wù)器（如Jenkins）對新分支進行自動化測試。當代碼通過自動化測試和代碼審查之后，該分支的代碼被合并到master分支。再從master分支部署到生產(chǎn)環(huán)境。圖2是GitHubflow分支流程的示意圖。
圖2.Githubflow中的分支流程的示意圖
GitHubflow的好處在于非常簡單實用。開發(fā)人員需要注意的事項非常少，很容易形成習(xí)慣。當需要進行任何修改時，總是從master分支創(chuàng)建新分支。完成之后通過pullrequest和相關(guān)的代碼審查來合并回master分支。GitHubflow要求項目有完善的自動化測試、持續(xù)集成和部署等相關(guān)的基礎(chǔ)設(shè)施。每個新分支都需要測試和部署，如果這些不能自動化進行，會增加開發(fā)人員的工作量，導(dǎo)致無法有效地實施該流程。這種分支實踐也要求團隊有代碼審查的相應(yīng)流程。
git-flow應(yīng)該是目前流傳最廣的Git分支管理實踐。git-flow圍繞的核心概念是版本發(fā)布（release）。因此git-flow適用于有較長版本發(fā)布周期的項目。雖然目前推崇的做法是持續(xù)集成和隨時發(fā)布。有的項目甚至可以一天發(fā)布很多次。隨時發(fā)布對于SaaS服務(wù)類的項目來說是很適合的。不過仍然有很大數(shù)量的項目的發(fā)布周期是幾個星期甚至幾個月。較長的發(fā)布周期可能是由于非技術(shù)相關(guān)的因素造成的，比如人員限制、管理層決策和市場營銷策略等。
git-flow流程中包含5類分支，分別是master、develop、新功能分支（feature）、發(fā)布分支（release）和hotfix。這些分支的作用和生命周期各不相同。master分支中包含的是可以部署到生產(chǎn)環(huán)境中的代碼，這一點和GitHubflow是相同的。develop分支中包含的是下個版本需要發(fā)布的內(nèi)容。從某種意義上來說，develop是一個進行代碼集成的分支。當develop分支集成了足夠的新功能和bug修復(fù)代碼之后，通過一個發(fā)布流程來完成新版本的發(fā)布。發(fā)布完成之后，develop分支的代碼會被合并到master分支中。
其余三類分支的描述如表1所示。這三類分支只在需要時從develop或master分支創(chuàng)建。在完成之后合并到develop或master分支。合并完成之后該分支被刪除。這幾類分支的名稱應(yīng)該遵循一定的命名規(guī)范，以方便開發(fā)人員識別。
表1.git-flow分支類型
對于開發(fā)過程中的不同任務(wù)，需要在對應(yīng)的分支上進行工作并正確地進行合并。每個任務(wù)開始前需要按照指定的步驟完成分支的創(chuàng)建。例如當需要開發(fā)一個新的功能時，基本的流程如下：
- 從develop分支創(chuàng)建一個新的feature分支，如feature/my-awesome-feature。
- 在該feature分支上進行開發(fā)，提交代碼，push到遠端倉庫。
- 當代碼完成之后，合并到develop分支并刪除當前feature分支。
在進行版本發(fā)布和hotfix時也有類似的流程。當需要發(fā)布新版本時，采用的是如下的流程：
- 從develop分支創(chuàng)建一個新的release分支，如release/1.4。
- 把release分支部署到持續(xù)集成服務(wù)器上進行測試。測試包括自動化集成測試和手動的用戶接受測試。
- 對于測試中發(fā)現(xiàn)的問題，直接在release分支上提交修改。完成修改之后再次部署和測試。
- 當release分支中的代碼通過測試之后，把release分支合并到develop和master分支，并在master分支上添加相應(yīng)的tag。
因為git-flow相關(guān)的流程比較繁瑣和難以記憶，在實踐中一般使用輔助腳本來完成相關(guān)的工作。比如同樣的開發(fā)新功能的任務(wù)，可以使用gitflowfeaturestartmy-awesome-feature來完成新分支的創(chuàng)建，使用gitflowfeaturefinishmy-awesome-feature來結(jié)束feature分支。輔助腳本會完成正確的分支創(chuàng)建、切換和合并等工作。