版本控管系統:版本控管係為「建構管理 (configuration management)」的範疇。理論上,關於「分支 (branch)」與「標籤 (tag)」,從觀念上來看在各版控系統應是類似的,只是做法不同罷了。

Suversion vs. Git:雖然兩者常被拿來比較的是,subversion 是集中式的儲庫 (repository),而 Git 則為分散式的。但若從專案管理者的角度來看,要管理的其實只有一個:位於伺服器上的儲庫。即使如 Git 可以有一堆分散式的儲庫,但管理者真正只有管理到例如儲存在 GitHub (or private Git server)上的儲庫。至於開發者在私人的儲庫內,要如何分支與標籤是自己的事,只要最終能提交給專案管理者做合併 (merge)即可。

關於版本控管的分支與標籤說明範例
(點擊圖片鏈接看原圖)圖、關於版本控管的分支與標籤說明範例

    關於分支 (branch):

  • 原則上,任一版本管控系統只有一條主幹,例如 suversion 稱為 trunk,Git 稱為 master。
  • 每一次對開發文件的提交 (commit),可視為是一個節點 (node)。節點會持續隨開發時間推進,並期能達成所設定的里程碑 (milestone)。
  • 如果把主幹的任一節點當成是可能對外發布的釋出 (release),而這些釋出不希望與開發/維護期間的文件相互干擾,則可以另闢其它分支 (branch),可與主幹並行開發並個別維護。主幹與分支(可能多個)盡量將耦合性 (coupling)降低,讓版本釋出與開發維護得以順暢並行。
  • 分支後的開發/維護的節點,最終仍需將修改的文件回到主幹上,此時就必須做「合併 (merge)」的動作。

    關於標籤 (tag):

  • 標籤很單純,就僅是為任一節點 "貼" 上具名稱的識別而已。
  • 一般而言,主幹上的標籤命名,大多與版本釋出有關。例如「v0.8b」代表的是該節點所發布的版本。
  • 分支上的標籤命名,多與 Issue/Bug 有關。Issue 代表著預定要完成的功能或 User 所期望的新功能;Bug 則為已被發現的問題,必須解決。
  • 有時候,分支與標籤令人模糊的是,可能「Issus」、「Hotfix (bug)」、「Feature」都被視為是個別的分支。這算是比較嚴謹的做法,在大型產品開發的分工很細的情況下,就可能以「分支」來細分;而若中小型產品/專案開發,分支過多可能也較不容易維護,此時可改以「標籤」的作法,為幾個主要的節點命名即可。

看圖說故事-簡單分支與標籤範例

上圖範例有一條主幹與一條分支。主幹採版控系統預設命名 (subversion-trunk, git-master),分支命名為「develop」。

C1 為起始節點,從 C1 → C2 至 C3 節點,此時為 C3 貼上標籤,命名為「V0.8b」,並發布為第一個釋出版本。

版本發布後,不希望被後續的開發影響,故而開闢一條「develop」分支,從 D1 → D2 → D3 持續開發循環。

在 D3 節點,解決了原來釋出版本的一個重大問題,所以標記該節點名為「V0.8Hotfix」,並合併 (merge)回主幹上的 C4 節點,同時 C4 節點標記為「V0.8.1b」,作為小幅改版的釋出。

從 C4 分叉 (fork)到 deveop 分支,繼續兩個開發循環 (D4 → D5),而 D5 也完成在 Issue Tracking 系統內所記錄的編號 016 功能,故將其節點標記為「Issue-016」,並合併回主幹成為 C5 節點,並標記為「V0.9」,作為第三個版本的釋出。

分叉回 develop 分支,繼續著 D6 → D7 → D8 的開發循環。當完成某些特定功能或解決某些 bug 後,準備合併回主幹,再繼續下一個版本的釋出 ...。

※ 參考資訊
 o Revision control
 o Git online document-chapter3-Git 分支(簡體中文)
 o Developing and Deploying with Branches