什么是代碼分支
在代碼開發中,我們為了方便版本管理和開發、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分支合并到主分支。這時候,主分支再一次跟生產環境保持一致了。