Friendbuy是一家互聯(lián)網(wǎng)創(chuàng)業(yè)公司。產(chǎn)品的源代碼是托管在GITHUB上的。在EC2上有三套環(huán)境：生產(chǎn)環(huán)境，測試環(huán)境和持續(xù)集成環(huán)境。基本上每天都有大量的代碼被提交，測試和部署。一年多的磨合下來，逐漸理順了GIT的使用流程。但是，最開始并不是這樣的，所有的開發(fā)人員都沒有使用過GIT，基本上都是SVN的背景。

最開始的使用方式

只有一個GIT分支，就是MASTER。開發(fā)團隊直接向MASTER提交新的改動，部署其實就是在生產(chǎn)環(huán)境下執(zhí)行

git pull

開發(fā)人員的日常工作也很簡單

git pull --rebase
git commit -a -m "xxxx"
git push

基本上是把Git當作SVN來使用。

生產(chǎn)環(huán)境不穩(wěn)定

很快就出現(xiàn)了問題。在一次給客戶的演示的過程中，掉鏈子了。

老板很不高興，對于生產(chǎn)環(huán)境部署的質(zhì)量產(chǎn)生了懷疑。

于是為了使得生產(chǎn)環(huán)境穩(wěn)定，團隊決定犧牲時效性，建立更加正規(guī)的流程，添加了測試環(huán)境和自動集成環(huán)境

每次提交的代碼都會被自動集成環(huán)境自動進行測試

不定期的會人工部署到測試環(huán)境中測試

當測試環(huán)境測得差不多的時候才會決定部署到生產(chǎn)環(huán)境

另外每次部署到測試環(huán)境和產(chǎn)品環(huán)境的時候都會打一個標簽

git tag -a xxx -m xxx

速度就是生命

眾所周知，互聯(lián)網(wǎng)創(chuàng)業(yè)公司玩的就是速度。加上了這么一套流程之后，一個feature要發(fā)布變得非常冗長。

最要命的是，網(wǎng)站為了嘗試不同的風(fēng)格，還經(jīng)常全面改版。每次完整的改版都要協(xié)調(diào)各方面的資源，特別是有一個很長的UI調(diào)整過程。

問題是在網(wǎng)站局部改版的情況下，客戶的其他特性仍然要響應(yīng)，產(chǎn)品的線上BUG仍然要FIX。

于是就有了分支。

git branch new-retailer-site master
git checkout new-retailer-site
#change some thing
git commit -a -m "xxx"
git push origin new-retailer-site

分支用完了之后，要合并到master中

git checkout master
git merge new-retailer-site
#fix conflit
git commit -a -m "xxx"
git push

最后就可以把分支刪除了

git push origin :new-retailer-site

千萬不能搞亂master

分支在很短的時間就沖到了兩位數(shù)。對于分支的管理一開始也并不在意。

直到出了這么一個事情：

開發(fā)團隊一致決定new-retailer-site已經(jīng)差不多了，可以“準備”發(fā)布了。然后new-retailer-site被合并到了master中。

然后在master上有開發(fā)了一些其他特性。

但是new-retailer-site的UI遲遲不能夠讓人滿意。直到有一天開發(fā)團隊被要求先把master中的“有用”的feature發(fā)布，樣式改版工作延后發(fā)布。

這可難辦了，所有的改動已經(jīng)混雜在同一個分支中了。

最后的解決辦法是用

git log

把一條條的改動給找出來，由于比對實在太麻煩了，還寫了點代碼來干這事

def list_commits(branch):
　　commits = local('git log ' + branch + ' ^master --no-merges --format=format:%s,%H', capture=True)
　　commits = commits.split('\n')
　　for commit in commits:
　　　　print('==> %s <==' % commit.split(',')[0])
　　　　print('https://github.com/friendbuy/apps/commit/%s' % commit.split(',')[1])

然后把找出來的commit，一條條cherry pick出來

git cherry-pick <commit id>

接下來很長一段時間都是搞不清楚，到底是哪個分支是產(chǎn)品部署的分支。

直到某一天，團隊決定以后再也不能隨便把無關(guān)分支合并到master了。

正常的工作流程應(yīng)該是，選定要候選發(fā)布的branch，比如說new-retailer-site

git checkout new-retailer-site
git merge master
# fix conflict
git commit -a -m "merge"
git push

然后在測試環(huán)境下

git checkout new-retailer-site
git pull

測試通過了之后，確定可以發(fā)布到產(chǎn)品環(huán)境了

git checkout master
git merge new-retailer-site
git push

然后把剩余的分支，逐個更新

git checkout feature-branch-1
git merge master
# ...
git checkout feature-branch-2
git merge master
# ...

總結(jié)

使用feature branch的方式，可以同時進行很多項特性的開發(fā)，并有產(chǎn)品的需要決定什么時候發(fā)布哪些特性。比如在圣誕節(jié)期間，基本上就沒有feature branch被發(fā)布，但是開發(fā)并不會因此停滯。而且業(yè)務(wù)的優(yōu)先級經(jīng)常調(diào)整，經(jīng)常開發(fā)到一半的分支也會被扔掉。

在使用多分支開發(fā)的時候要保持一個master分支始終對應(yīng)“一定會被發(fā)布到產(chǎn)品環(huán)境的代碼”，以master為中心保持一致的合并方向，不然分支之間亂合并就很難管理了。

目前有一個缺陷是持續(xù)集成環(huán)境只對master進行測試，理想的情況下應(yīng)該建立一個staging的分支，持續(xù)集成環(huán)境也要對staging分支進行測試。