幾乎所有的版本控制工具都有branch功能，branch主要用于以下幾個(gè)場(chǎng)景：
1，控制產(chǎn)品OEM。
基本上做產(chǎn)品，不同的客戶(hù)都會(huì )提出多種不同特性需求，最簡(jiǎn)單的例子就是LOGO和標題完全不一樣。但是可能產(chǎn)品自身的大部分功能和模塊的代碼一樣的，這個(gè)時(shí)候如何管理多個(gè)客戶(hù)定制的功能特性，并且不會(huì )干擾其他OEM版本的功能呢？
如果你一開(kāi)始就用if加N多變量定義的話(huà)，早晚會(huì )累死你，如果你把代碼拷貝很多份，每多一個(gè)新的OEM就多拷貝一份代碼，那如果發(fā)現公用模塊里面有個(gè)BUG，難道你要每個(gè)版本的源代碼都要修改？萬(wàn)一改錯地方了，或者哪個(gè)版本的忘記改了，又是一件麻煩事。
這個(gè)時(shí)候我們就可以考慮使用branch功能，在第一個(gè)OEM的基礎上分支出第二個(gè)OEM，第三個(gè)OEM完全取決于和哪個(gè)版本更像，就在那個(gè)版本的基礎上做新的分支，有新的OEM特性需求，就切換到那個(gè)分支上修改，放心，所有的的單獨分支上的代碼看起來(lái)都是獨立的，不會(huì )影響其他版本。
2，多人協(xié)作長(cháng)時(shí)間開(kāi)發(fā)功能模塊
如果你在一個(gè)團隊中，那幾乎很難做到每天都能按期完成某個(gè)模塊功能，并且測試通過(guò)。那團隊成員又必須每日下班前把自己的代碼保存一下，萬(wàn)一機器故障了之類(lèi)的還能有代碼備份機制。如果提交了不能工作的代碼，別人又獲取到了，那其他人的事情就做不下去了。所以，branch另外一個(gè)適用場(chǎng)景就是為team單獨成員開(kāi)辟個(gè)人工作區域，單元測試無(wú)誤之后再把成員的工作代碼合并到主分支中，既能達到個(gè)人代碼備份的目的，又能不影響其他人的工作。
其實(shí)上面所說(shuō)的就是rebase和merge的不同適用場(chǎng)景。
在場(chǎng)景1的情況下，如果修改了某個(gè)公用代碼的BUG，這個(gè)時(shí)候就應該是把所有的OEM版本分支rebase到這個(gè)修復BUG的分支上來(lái)，在rebase過(guò)程中，Git會(huì )要你手動(dòng)解決代碼上的沖突，你需要做的就是把修復BUG的代碼放到目標分支代碼里面去。rebase的結果是：所有的分支依然存在
在場(chǎng)景2的情況下，因為成員的代碼開(kāi)發(fā)工作已經(jīng)完成了，也不需要再保留這個(gè)分支了，所以我們可以把這個(gè)成員分支merge到主分支上，當然沖突在所難免，手工解決的工作肯定逃不掉，但是利大于弊不是嗎。merge以后，分支就不存在了，但是在Git的所有分支歷史中還能看到身影。
根據適用場(chǎng)景不同，采用不同的分支合并策略，讓你團隊的代碼保持生命力吧。
聯(lián)系客服
