什么是代碼分支

在代碼開發中，我們為了方便版本管理和開發、bug修復等工作，將代碼分開不同的版本，開發人員使用不同的版本開發時，看到的文件可以完全不沖突，各自開發各自的功能。叫做不同的代碼分支。

創建分支時總是在以前的分支基礎上復制出來的

分支創建后，在新創建的分支上開發雖然不影響原來分支的代碼，但并不意味著新分支的代碼是憑空產生的，兩者完全不搭邊。新分支總是從舊分支中復制出來的，然后才在上面修改。我們當然可以將新分支的文件全部改成面目全非，但這樣有意義嗎？這樣做這兩個分支還怎么合并呢？所以，新分支與舊分支之間其實最終差異應該都不大。比如，新分支是用來開發一個小功能的，兩個分支最終只有十幾個文件發生了修改，合并起來也不會有太多的沖突。

開發人員應重視版本管理

上次大眾創新獎的開發影響到立項的測試，就是因為我們一直沒有重視版本和分支管理導致的。我認為我們應該吸取這次教訓。相對規范的分支管理有助于我們更好的管理代碼，甚至大家開發時可以互不影響，也方便測試。

創建分支的原則

那么，我們應該如何使用分支呢？我們應該用什么樣的原則去創建和使用代碼分支？

開發互不影響

創建分支是為了開發人員開發新功能時互不影響。這是最基本的原則。如果A和B兩個開發各自正在開發不同的新功能，那么他們應該各自在本地創建出各自的分支，并在各自的分支上進行開發。那么，他們開發的中間各自是不會產生沖突文件的。

修改bug不需要創建專門的分支

有些開發人員可能會有疑問：難道改一個bug也要專門創建一個分支嗎？我認為這大可不必，一方面，這太麻煩，也不是不可以；另一方面，分支是添加新功能時用到的，這不符合這個原則。

合并分支時，沖突應該是很少的

分支合并是分支管理最常用到的功能。如果沒有合并，分支也就失去了意義。然而，合并分支一個麻煩事就是文件沖突了。兩個分支同時修改了同一個文件的同一行，合并分支時就會發生文件沖突。然而，好的分支管理這種沖突應該是很少的，否則開發人員應仔細分析沖突代碼后再合并。

生產環境版本上去后，應立即創建新的代碼分支

原來的代碼分支屬于歷史分支，可以用來進行代碼歷史版本備份。

我們的項目如何進行分支管理

以我們雙創為例，我們應當如何進行分支管理呢？這里沒有絕對正確的意見，我以我自己的角度，結合項目實際，談談自己的想法。

主分支保持跟生產環境代碼一致

我們把生產環境目前的代碼所在的分支稱為主分支。只有生產環境進行版本變更時，主分支的代碼才會發生改變。而且，開發人員一般不會直接修改主分支的代碼，主分支代碼的變更都是通過合并其他分支產生的。

創建一個bug修復分支，用來修改已發現的主分支上的bug

當生產環境版本發生變更后，我們馬上創建一個新的分支作為主分支（原來的主分支作為歷史分支，備份代碼了，我們不會再修改它）。這時候主分支的代碼跟目前生產環境的代碼一致。現在，在主分支的基礎上，我們又復制一個新的分支，稱為bug修復分支。開發人員可以在這個bug修復分支上修復bug。

開發新功能

一般情況，開發人員需要同時開發新功能和修復舊版本bug的任務。修復bug的分支上面已經講過了，那么，開發人員如何在開發新功能時，跟其他人的任務不發生沖突呢？最好的辦法就是開發新功能時，在修復bug的分支基礎上checkout出新功能的開發分支來（本地創建即可）。開發并自測完成后，再切到修復bug分支上，將新功能分支合并過來。這樣，修復bug的分支bug被修復，同時新功能也不斷被合并過來。

合并修復bug分支到主分支

開發人員在修復bug分支上產生多個beta版本供測試人員測試。當測試人員認為版本測試通過，可以打包到生產環境時，開發人員切到主分支，正式將修復bug分支合并到主分支。這時候主分支的代碼應該會跟當前測試環境的代碼一致（修復bug分支與主分支代碼一致）。這時候，相當走完了一個生產環境版本變更流程，之后按照上述的方法進行版本管理即可。

hotfixs

最后，我們討論一下hotfixs。hotfixs我們用得比較少，其實很多規范的項目都有這個概念和做法。
當版本上生產環境后，如果我們發現的影響很大的bug時，不可能又上一個新版本解決這個問題。這時候我們通常在主分支的基礎上創建出一個hotfixs分支，然后在這個分支上緊急修復bug，然后將修改過的文件直接替換到生產環境（注意，不會重新打包）。替換完成后,再將hotfixs分支合并到主分支。這時候，主分支再一次跟生產環境保持一致了。