版本控管系統：版本控管係為「建構管理 (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。