程序版本（分支）管理策略

程序版本（分支）管理策略

• 當前很多項目實施現場都採用登記簿（excel）的方式管理程序版本，而且每次版本部署都是採用增量發佈class文件的方式。這種手工的管理方式，生產處理效率低下，開發人員或版本管理人員容易遺漏代碼。如果管理不善，線上代碼已經無法找到其源代碼，還得靠反編譯class的方式獲取源代碼。

• 當今互聯網化的IT開發模式下，程序版本更迭快，運維需要打包、測試、發佈等操作都線上自動化，上面這種手工管理模式已經無法滿足，需要更爲規範和高效的程序版本管理策略。

• Vincent Driessen提出了一個分支管理的策略，非常值得借鑑。它可以使得版本庫的演進保持簡潔，主幹清晰，各個分支各司其職、井井有條。理論上，這些策略對所有的版本管理系統都適用。

主分支（Master）

• 程序庫應用有且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個分支上通過Tag進行標記不同版本。主分支應該只有版本管理員纔能有讀寫入權限，其他人員只有讀權限，以此來保證主分支程序的正確性。一般在程序庫未正式發佈（上線）前，其主分支應該沒有任何代碼；當程序庫正式發佈第一個版本時，版本管理員會將該正式版本代碼分支代碼合併到主分支上，並打上Tag標記，這樣就形成了第一個版本的主分支。

  Git主分支的名稱Master。
  

開發分支（Develop）

• 主分支只是用來標記正式版本，並不用於開發。新建項目（還未發佈）程序的日常開發應該在另一條分支上完成，這個分支我們稱之爲開發分支，也叫做Develop，通常使用git的管理者一般將該分支簡寫成dev。

• 正式對外發布第一個版本時，就可以將開發分支的最新代碼合併到主分支上，且主分支Tag標記上第一個版本號。一旦項目代碼已經發布第一個版本，所有開發人員都不能再使用開發分支（Develop）進行新的功能開發了（需要新建分支進行新功能開發，後面會講到）。開發分支（Develop）此時就轉換成了“集成分支”，其分支下的代碼始終體現下個待發布版本的代碼。
  

輔助性分支

• 輔助性分支與關鍵分支（master和develop）一起，用來支持團隊成員們並行開發，使得易於追蹤功能，協助生產發佈環境準備，以及快速修復實時在線問題。與關鍵分支不同，這些分支總是有一個有限的生命期，因爲他們最終發佈後會被移除。
  輔助性分支主要有三種：

功能（feature）分支
預發佈（release）分支
修復bug（fixbug）分支

功能（feature）分支

• 它是爲了開發某種新需求功能建立的分支，是從Develop分支上面分出來的。功能分支只是這個功能處於開發狀態時他就會存在，如果確認該功能將在下一個發佈版本發佈，則需要將該功能分支合併到Develop分支上；如果該功能確認不在需要，可以直接刪掉該分支。這樣就保證了Develop分支始終體現下一個待發布版本的代碼。
• 功能分支一般採用feature-*的命名形式，一般功能分支以需求功能命名比較合適，不能以版本號命名，因爲你還不知道具體的版本安排。一般軟件生命週期：開發、SIT測試、UAT測試的幾個階段將使用功能分支來管理。
  

預發佈（release）分支

• Release分支是從Develop分支創建而來，最後一定會合併到Develop和Master分支上，一般採用release-${版本號}的命名形式。
• Release分支是爲新版本的發佈做準備的，該分支允許我們在最後時刻做一些細小的代碼修改、小BUG的修改，以及準備發佈的元數據（版本號，發佈時間等等）。在Release分支創建的時候要爲即將發行版本分配一個版本號，因爲直到此時，Develop分支反映的變化都是爲了下一個發行版，但是在Release分支創建之前，下一個發行版到底叫0.8.0還是1.0.0是不明確的。這個決定是在Release分支創建時根據項目在版本號上的規則制定的。建議的版本號的分配規則：x.y.z，x、y、z都是大於等於零的整數，一般項目的第一個版本號：0.1.0

x：在發生重大功能變更時，又或者版本無法向下兼容時，該整數加一，同時y和z歸零
y：在添加了新的業務功能或者刪除了部分功能，該整數加一，同時z歸零
z：解決了一些線上BUG、做了一些技術優化等非功能性，該整數加一

• 按照上面的版本號的規則，Release分支應該在y上加一，即：原版本號是：0.1.0，下個發佈的Release版本號應該是：0.2.0。當然也可能是x上加一，即：原版本號是：0.1.0，下個發佈的Release版本號應該是：1.0.0，者取決於該預發佈版本功能變更的情況。
• 從Develop分支創建新的Release分支的關鍵是Develop分支達到了預發佈的理想狀態，也就是所有這次要發佈的features分支必須在這個時點及時合併到Develop分支。對於所有下一個版本準備發佈的features分支必須等到Release分支創建以後才能再合併，實際操作中建議等該Release版本發佈後，且已經將代碼合併到Develop和Master分支上以後，才能將下一個版本準備發佈的features分支合併到Develop分支上，再安排下一個版本的Release分支。
• Release分支創建完成後，需要版本管理員對比Release分支與Master分支之間的代碼，如果發現明細問題的程序需要修改並測試。另外需要安排該預發佈分支進行上線前的迴歸驗證測試，驗證測試發現的BUG開發人員應該在該分支上進行修改（而不是修改到Develop分支上），直到測試達到預期目標該版本程序穩定並封版。在Release分支上嚴謹增加大的features新功能代碼，正確做法應該是基於Develop分支建立單獨的功能分支，進行開發、SIT測試、UAT測試後，再將這些新功能分支合併到Develop分支上，然後等待創建下一次的預發佈分支（版本）。爲了便於版本先後的管理，未來發布版本的Release分支有且只有一個。
• 當一個Release分支迴歸測試完成後，準備好成爲一個真正的發行版的時候，下面這些工作必須完成。
• 第一步、需要再次覈對當前Release分支與Master分支之間的代碼，避免未測試的程序偷偷的被上線；
• 第二步、當前Release分支下構建部署物（當前架構中多用Maven進行管理），並上傳部署物到生產環境準備，完成部署後進行生產驗證；
• 第三步、生產驗證正常的情況下，將Release分支要合併到Master上，合併後Master分支就是最新的程序版本了。然後對Master分支打一個版本標籤Tag（標籤的命名建議採用Tag-${版本號}格式），以便以後更加方便的引用這個歷史版本。最後，在Release分支上的修改必須合併到Develop分支上，以便未來發行版也包含這些已經發行的功能；如果實際分支管理中出現了多個在途的預發佈（Release）分支，版本管理員必須在生產驗證正常的情況下，將剛上線的Release分支的代碼合併到其他在途Release分支上去(最好不要出現這種多個在途Release分支的情況)，合併是注意版本號的衝突；
• 第四步、合併完成後，刪除該Release分支；
  Release、Feature、Develop分支的關係如下圖：
  

修復bug（fixbug）分支

• 應用軟件正式發佈後，難免會出現一些BUG。BUG應該根據問題的緊急層度，分而治之。不太緊急的BUG可以在某個功能（feature）分支下修改代碼，並放到下一個預發佈（Release）的版本進行發佈。比較緊急的BUG就需要創建當前這種修復bug分支，一般採用fixbug-${版本號}的命名形式。
• 修復bug（fixbug）分支與預發佈（Release）分支很相似，它們都是爲新的生產版本發佈做準備，儘管這未在你的生產版本計劃之內。修復bug（fixbug）分支應該基於Master分支上對應與生產版本的標籤Tag創建而來。其本質是團隊中大部分成員在其Feature分支、Release分支的工作可以繼續，而修復bug的人員準備基於Fixbug分支進行生產環境問題的快速修復。
• 同Release分支一樣，Fixbug分支在創建時也要指定其具體的版本號，按照上面的版本號的規則，Fixbug分支應該在z上加一，即：原版本號是：0.1.0，下個發佈的FIxbug版本號應該是：0.1.1。
• 在整個Fixbug分支下進行bug修復開發後，也需要安排該Fixbug分支進行上線前的驗證測試，驗證測試發現的BUG開發人員應該在該分支上進行修改，直到測試達到預期目標該版本程序穩定並封版。爲了便於版本先後的管理，未來發布版本的FIxbug分支有且只有一個。
• 當一個Fixbug分支測試完成後，準備好成爲一個真正的發行版的時候，下面這些工作必須完成。
• 第一步、需要覈對當前FIxbug分支與Master分支之間的代碼，避免未測試的程序偷偷的被上線；
• 第二步、當前Fixbug分支下構建部署物（當前架構中多用Maven進行管理），並上傳部署物到生產環境準備，完成部署後進行生產驗證；
• 第三步、生產驗證正常的情況下，將Fixbug分支要合併到Master上，合併後Master分支就是最新的程序版本了。然後對Master分支打一個版本標籤Tag（標籤的命名建議採用Tag-${版本號}格式），以便以後更加方便的引用這個歷史版本。最後，在Fixbug分支上的修改必須合併到Develop分支上，以便未來發行版也包含這些已經修復的bug；如果實際分支管理中出現了多個在途的FIxbug分支，版本管理員必須在生產驗證正常的情況下，將剛上線的Fixbug分支的代碼合併到其他在途Fixbug分支上去(最好不要出現這種多個在途Fixbug分支的情況)，合併是注意版本號的衝突；
• 第四步、合併完成後，刪除該Fixbug分支；
• 關於Release分支與Fixbug分支有一個例外，兩者分支同時並存的情況，我們分兩種情況來討論：
  正常情況下Fixbug分支應該比Release分支先進行生產發佈，那麼Fixbug分支除了合併到Develop分支和Master分支外，應該還要合併到該Release分支中。避免出現該Release分支發佈時不含Fixbug分支修改的內容；
• 如果出現Release分支比Fixbug分支先進行生產發佈，可以同上將Release分支合併到Fixbug分支。另外大多數情況下Fixbug分支下修改的代碼量較小，也可以重新從合併該Release分支的Master分支中拉一個新的Fixbug分支，並將當前Fixbug分支的修改代碼合併到新的Fixbug分支上，並將原Fixbug分支刪除；
  Master、Fixbug、Develop分支的關係如下圖：
  
• 程序版本（分支）管理沒有太多新穎的東西，主要是要求版本管理人員的細心，以及與其他開發人員的協同。整個程序版本管理並不是版本管理人員一個人的事情，需要整個團隊人員都要理解並遵照執行，才能達到預期效果，我們再也不能通過手工檯賬的方式進行版本管理了。