在 Git 裡面 分支 (Branch) 是個非常重要的機制，使用上也必須特別小心，因為專案總不能無限制的「分支」下去，最終總是要合併的，但合併是日後的議題。今天「暢想資源」就來向大家略略介紹一下Github分支的基本概念

介紹

在版本控管中使用「分支」機制，最主要的目的就是用來解決開發過程中版本衝突的問題。筆者認為，有許多曾經用過任何版本控管機制的人，都會認為「分支」是個「產生版本衝突」的元兇，因為當你開始分支之後，一定就會想到合併的議題，而當分支之後，若是有人跟你一樣修改到相同檔案的相同一行時，就會引發「版本衝突」，而只要發生衝突，就必須費心解決。

當衝突發生時，有時可以很輕易的決定要用自己的版本或是對方的版本，但有時卻沒那麼容易，複雜的時候還要依據衝突的片段，找到當初改過這幾行的人出來，協調出彼此的變更對系統的影響，最後決定要怎樣合併，諸如此類的問題非常繁瑣，也因此很多人會盡力避免「分支」的情況發生，以免發生「衝突」。

不過，若是開發團隊越來越大，系統功能越來越多，就算你不對版本做分支，大家的衝突情況一樣也會層出不窮，有時候還不是衝突的問題，而是 A 寫好一個功能，但被 B 的後續版本給蓋掉了，然後沒有任何衝突發生，這也不是大家所樂見的。然而，這也是一種「無形的衝突」狀況。

以前在集中管理的 Subversion 版控機制中，也有分支的概念，也可以運作的很好。當然，如果你的軟體架構不夠好，如果你對分支的概念、工具的使用也不是很清楚，我相信使用「分支」時也不會多順利，這是個必然的結果，這世界絕不會有「免學、無痛、自然學會分支」的這種版本控管工具出現，事在人為，人的觀念不對，用什麼工具都不會順的

由於 Git 屬於「分散式版本控管機制」，在分散式版本管理的使用情境中，最不想做的事情就是「管理」，所以 Git 很少有所謂的管理機制或權限控管機制，它唯一想做的僅僅是讓大家可以順利的「分支」與「合併」而已

舉個例子：從我們使用 git clone 指令開始，其實就是「分支」的開始，你從遠端儲存庫複製一份完整的儲存庫下來，然後開始在自己的本地端建立版本，等軟體修訂到一定程度後再「合併」回去，只是這時合併的指令叫做 git push 而已

這種分支與合併的情形，在 Git 版本控管的過程中無所不在，遠端的儲存庫可以有分支，本地的儲存庫可以有分支，你可以從遠端任何一個分支合併(pull)到本地分支，也可以將本地的分支推向(push)遠端的分支，你當然也可以從本地任何一個分支合併(merge)到本地的另一個分支。可以想見，如果「分支」沒有一套良好的控管邏輯，最後可以組合出各種極其複雜的版本控管使用情境，這也不是大家所樂見的。因此，好好學會「分支」與「合併」真的非常重要。例如 git-flow 就是一套廣受歡迎的分支管理模式，這不是一套工具，而是一種管理分支的邏輯，這部分在我未來的文章中將會加以說明

Linux kernel 發展的過程，在全世界有成千上萬的開發人員共同參與，為了管理這麼大量的開發團隊，Git 儼然而生，這是套分散式的版控機制，每個人都有完整的版本，版本散出去之後，大家必須管好自己的版本，然後遵照團隊的要求合併回來。然而，在合併回來之前，這套機制確保每個人都能夠順利的開發，不受任何其他開發人員的版本而影響，而 Git 確實做到了這點，同時又降低了版本控管的複雜度

當然，我也必須講，如果參與軟體開發的團隊只有兩三人，而且這些人還都聚在一起，那確實不一定要使用 Git 版本控管，使用 Subversion 也是個很好的選擇，簡單又直覺，開發的過程中若遇到問題，前後左右協調一下就能解決，這比讓整個團隊都來了解 Git 來的方便很多

如果你的團隊有點規模，或大家並沒有坐在一起工作，又要做版本控管的話，或許 Git 是個不錯的選擇，但工作團隊之間擁有一致的版控觀念或習慣，也是非常重要的一件事

版权信息

本文转载自“第 08 天：關於分支的基本觀念與使用方式”，并由“超级efly”整理（原作者版权所有）

历史上的今天

2013年：註冊「免費」Apple開發者帳號（11条评论）