Git的強大是眾所周知的，本文要分享的是關于"使用Git的分支和合并功能來進行版本管理的開發模型"。以下是譯文，原文地址
這篇文章我想介紹一下一年前就提到過的我所有項目(工作/私有)都在使用的開發模式，經過事實驗證，確實非常可行。很早就想寫了，一直沒騰出時間。我不會涉及項目的細節，只是談談分支的使用策略和發布管理。
上圖是使用Git這個版本控制工具來管理所有源碼的。
為什么使用Git
如果要看詳細的Git與集中式源碼管理工具的優勢與劣勢，可以參見這篇文章，那里有很多口水仗。作為一個開發人員，所有的源碼管理工具中，我最喜歡Git。Git從根本上改變了開發人員對分支和合并的使用，傳統的CVS/SVN，分支和合并都是高級話題，而且使用起來稍顯麻煩，隔一段時間才會用一次。但是有了Git，這些操作就成了家常便飯。
由于使用簡單，方便重復操作，分支和合并不再是讓人望而生畏的操作，版本管理工具應該盡可能地對分支/合并提供最好的支持。
工具談得差不多了，回到開發上。我待會要講到的模型其實是一些每個開發人員都應該遵守的步驟，如果想管理好軟件的開發流程的話。
分布式但集中化
我們要使用的倉庫是一個"中心庫"，當然這個中心庫只是被認為是這樣(因為Git是分布式的，從技術層面上來說是沒有中心庫的)，我們將把這個倉庫叫做"origin"，因為Git用戶都熟悉這個名字。
每個開發者pull和push到origin，但除了中心化的push-pull關系外，每個開發者還可以從其他開發者那pull changes。比如說，對于一個比較大的新特性，在把代碼提交到origin之前，很可能會安排2個或多個開發者。上圖中有幾個小團隊：Alice和 Bob，Alice和David，Clair和David。
從技術角度來說，其實就是Alice定義了一個叫Bob的Git remote，指向到Bob的倉庫。
main分支
中心倉庫有兩個分支：
origin上的master分支，Git用戶應該很熟悉，跟master并行的有一個develop分支
我們把origin/master作為主要分支，源碼的HEAD總是表示production-ready(可隨時部署)狀態。而origin/develop上的代碼是為下一次的代碼發布準備的。每日構建也是基于此分支。
當develop分支達到了一個穩定狀態并準備發布時，所有的改變都要合并到master分支，并標上版本號。如何實現的下面細說。
這樣每次與master合并都會有新的部署發布。這點可以自動化，如使用Git hook腳本來實現自動部署代碼到線上。
支持(supporting)分支
我們的開發模型使用了一些支持分支放在master和develop分支的旁邊，方便開發小組之間的并行開發。不像main分支，這些分支是有時間限制的，因為他們最終都會被移除。
我們會使用到的不同的分支
- Feature branches
- Release branches
- Hotfix branches
每個分支都有各自的作用，并且有嚴格的規定，如：只能從哪個分支上去新開分支，只能合并到那個分支。這個待會細說。
Feature branches
繼承分支: develop
合并分支：develop
命名規范：除了master,develop,release-,hotfix-
Feature branches是用來開發新特性的(短期，遠期都可以)。當開始開發新特性時，很可能不知道這個特性會出現在哪個目標版本。一旦開發完成就可以合并到develop，當然如果開發失敗，就可以拋棄。
創建一個 Feature branch
當要創建一個新特性時，從develop分支上再進行分支
$ git checkout -b myfeature develop Switched to a new branch "myfeature"
新特性完成時，可以合并到develop
$ git checkout develop Switched to branch 'develop'
$ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes)
$ git branch -d myfeature Deleted branch myfeature (was 05e9557).
$ git push origin develop
—no-ff (譯者注：no fast foward)標簽，使得每一次的合并都創建一個新的commit記錄。即使這個commit只是fast-foward，這樣可以避免丟失信息
不幸的是，我沒有找到讓—no-ff成為commit默認參數的方法(譯者注：修改.consolerc?)，但確實應該提供一個方法。
Release branch
繼承分支: develop
合并分支：develop 和 master
命名規范：release-*
Release branch 是為新的production release準備的(譯者注：相當于RC版)，可以有一些小的bug，并為發布準備一些元數據(版本號，構建日期等等)。把所有的這些工作都放到 Release branch，develop branch就能更清晰地知道下一個版本要開發哪些特性。
從develop分支合并到release分支的關鍵因素是:develop分支達到了release分支所要求的狀態。至少所有針對該release的特性要被合并。至于那些將來會有的特性可以先放一放。然后就是為接下來即將要發布的版本分配一個版本號。
創建一個Release branch
Release branch是通過develop分支而創建。舉個例子，假如1.1.5是當前的production release，然后會有一個比較大的版本發布。develop的狀態已經可以發布版本了，經過商榷后，決定發布為1.2版本(而不是1.1.6或 2.0)，所以我們創建一個release分支，并給這個分支一個新的版本號
$ git checkout -b release-1.2 develop Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)
這個新分支可能會存在一定的時間，直到可以被合并到production branch。這段時間內，bug修補可以在這個分支上進行(而不是develop分支)。添加新特性(尤其比較大的)是不允許的。最后還是要被合并到 develop，然后繼續在develop分支上開發，直到下一個版本。
完成一個release branch
當release branch已經準備就緒，需要做幾件事。首先，release分支被合并到master分支上(每一個提交到master上的commit都是一個新版 本，切記)。然后master上的commit都要添加tag，方便將來查看和回滾。最后release上所做的修改必須合并到develop分支上，保 證bug已被修補。
前兩個步驟：
$ git checkout master Switched to branch 'master'
$ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes)
$ git tag -a 1.2
為了把release上的改變保存到develop，我們需要合并到develop
$ git checkout develop Switched to branch 'develop'
$ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes)
這個步驟可能會導致沖突，如果這樣的話，解決沖突，然后再提交。
現在一切都完成了，可以把release branch干掉了。
$ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe).
Hotfix branch
繼承分支: master
合并分支：develop 和 master
命名規范：hotfix-*
Hotfix branch和Release branch有幾分相似，都是為了新的production release而準備的。比如運行過程中發現了bug，就必須快速解決，這時就可以創建一個Hotfix branch，解決完后合并到master分支上。好處是開發人員可以繼續工作，有專人來負責搞定這個bug。
創建Hotfix branch
Hotfix是從master分支上創建的。假如當前運行版本是1.2，然后發現有bug，但是develop還在開發中，不太穩定，這時就可以新開一個Hotfix branch，然后開始解決問題。
$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)
解決問題，一次或幾次commit
$ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)
完成Hotfix branch
當結束時，bugfix要被合并到master，同時也要合并到develop，保證下個版本發布時該bug已被修復。這跟release branch完成時一樣。
首先更新master和tag release
$ git checkout master Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes)
$ git tag -a 1.2.1
接下來與develop合并
$ git checkout develop Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes)
有一個例外，就是當一個release branch存在時，bugfix要被合并到release而不是develop，因為release最終會被合并到develop。
最后移除branch
$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).
總結
這個開發模型其實沒有什么新穎的，一開始提到的"大圖"確實在我們的項目起到了非常大的作用。這是很優雅的一個模型，很容易實現，也容易在團隊成員之間達成一致。
PS:需要這個模型大圖的，可以去原文地址下載
--EOF--
若無特別說明，本站文章均為原創，轉載請保留鏈接，謝謝