淺論中小型專案版控系統的基本分支(branch)規劃

關於版控的分支與標籤的基本觀念,可參考原來寫的一篇:關於版本控管系統的分支(branch)與標籤(tag)的區別

關於中小型專案規模的版控分支 (branch)規劃,個人以為應該至少有三條 (以 Git 為例):master, develop , issue。

master (主幹):作為對外版本的釋出 (release)。

develop (開發用分支):作為內部開發的主要分支。其內的開發版本並不會對外釋出。

issue (支援性分支):Bug/Hot-fix (臭蟲/重大更新), 新功能 (new feature) ...。一般紀錄於「Issue Tracking」系統內的 問題/功能 等待解決的 Issue,即會轉入該分支。

看圖說故事

中小型專案規模的版控分支規劃
(點擊圖片鏈接看原圖)圖、中小型專案規模的版控分支規劃


master 分支內的 C1, C2 節點仍為開發階段,尚未對外釋出。待至 C3 節點後,貼上標籤 (tag)-0.6,作為第一版的釋出,同時將分支轉至 develop-D1 節點,作為釋出後的內部開發循環起始點。

當開發在 D1 階段的同時,發現原釋出的 0.6 版本有重大問題 (bug),故馬上新增一支援性的分支-Issue,轉至 I1 節點。I1 節點為其貼上識別標籤-Hotfix 0.64,預告下一個釋出版本為 0.64。

問題解決後,I1 分別與 master 與 develop 作「合併 (merge)」的動作。合併後在 master 主幹上會推進至 C4 節點,並貼上標籤-0.64,作為第二個釋出的小幅修正版本。另在 develop 分支會推進至 D2 節點,並持續朝下一個開發循環推進 (D3 → D4)。

至 D4 節點,將已完成的功能 (含原來修正的問題),合併回 master 主幹-C5,貼上標籤-0.8,作為第三次的釋出。然後再轉回 develop 分支-D5,繼續開發循環。

在 D6 節點,「Issue tracking」系統內記錄著兩個問題,為解決該問題,所以轉入至 Issue-I2 分支。至 I3 節點終將此兩個問題完成,為表示此節點解決了問題編號 2&3,故將標籤命名為-Issue 2&3。由於這兩個問題可能只是某些功能的調整修正,並非重大的臭蟲,所以並沒有合併回 master 主幹立即釋出,而是只回併至 develop 分支-D7,繼續開發循環。

至 D8 節點,合併回 master 主幹-C6,貼上標籤名為 v1.0,代表正式版本的釋出。

※ 參考資訊
 o A successful Git branching model
 o Git 版本控制 branch model 分支模組基本介紹

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *