標籤:

GIT 特性分支開發流程

從原博客導入:我的GIT工作流程 - taowen - 博客園

Friendbuy是一家互聯網創業公司。產品的源代碼是託管在GITHUB上的。在EC2上有三套環境:生產環境,測試環境和持續集成環境。基本上每天都有大量的代碼被提交,測試和部署。一年多的磨合下來,逐漸理順了GIT的使用流程。但是,最開始並不是這樣的,所有的開發人員都沒有使用過GIT,基本上都是SVN的背景。

最開始的使用方式

只有一個GIT分支,就是MASTER。開發團隊直接向MASTER提交新的改動,部署其實就是在生產環境下執行

git pulln

開發人員的日常工作也很簡單

git pull --rebasengit commit -a -m "xxxx"ngit pushn

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

生產環境不穩定

很快就出現了問題。在一次給客戶的演示的過程中,掉鏈子了。

老闆很不高興,對於生產環境部署的質量產生了懷疑。

於是為了使得生產環境穩定,團隊決定犧牲時效性,建立更加正規的流程,添加了測試環境和自動集成環境

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

不定期的會人工部署到測試環境中測試

當測試環境測得差不多的時候才會決定部署到生產環境

另外每次部署到測試環境和產品環境的時候都會打一個標籤

git tag -a xxx -m xxxn

速度就是生命

眾所周知,互聯網創業公司玩的就是速度。加上了這麼一套流程之後,一個feature要發布變得非常冗長。

最要命的是,網站為了嘗試不同的風格,還經常全面改版。每次完整的改版都要協調各方面的資源,特別是有一個很長的UI調整過程。

問題是在網站局部改版的情況下,客戶的其他特性仍然要響應,產品的線上BUG仍然要FIX。

於是就有了分支。

git branch new-retailer-site masterngit checkout new-retailer-siten#change some thingngit commit -a -m "xxx"ngit push origin new-retailer-siten

分支用完了之後,要合併到master中

git checkout masterngit merge new-retailer-siten#fix conflitngit commit -a -m "xxx"ngit pushn

最後就可以把分支刪除了

git push origin :new-retailer-siten

千萬不能搞亂master

分支在很短的時間就衝到了兩位數。對於分支的管理一開始也並不在意。

直到出了這麼一個事情:

開發團隊一致決定new-retailer-site已經差不多了,可以「準備」發布了。然後new-retailer-site被合併到了master中。

然後在master上有開發了一些其他特性。

但是new-retailer-site的UI遲遲不能夠讓人滿意。直到有一天開發團隊被要求先把master中的「有用」的feature發布,樣式改版工作延後發布。

這可難辦了,所有的改動已經混雜在同一個分支中了。

最後的解決辦法是用

git log

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

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

然後把找出來的commit,一條條cherry pick出來

git cherry-pick <commit id>n

接下來很長一段時間都是搞不清楚,到底是哪個分支是產品部署的分支。

直到某一天,團隊決定以後再也不能隨便把無關分支合併到master了。

正常的工作流程應該是,選定要候選發布的branch,比如說new-retailer-site

git checkout new-retailer-sitengit merge mastern# fix conflictngit commit -a -m "merge"ngit pushn

然後在測試環境下

git checkout new-retailer-sitengit pulln

測試通過了之後,確定可以發布到產品環境了

git checkout masterngit merge new-retailer-sitengit pushn

然後把剩餘的分支,逐個更新

git checkout feature-branch-1ngit merge mastern# ...ngit checkout feature-branch-2ngit merge mastern# ...n

總結

使用feature branch的方式,可以同時進行很多項特性的開發,並有產品的需要決定什麼時候發布哪些特性。比如在聖誕節期間,基本上就沒有feature branch被發布,但是開發並不會因此停滯。而且業務的優先順序經常調整,經常開發到一半的分支也會被扔掉。

在使用多分支開發的時候要保持一個master分支始終對應「一定會被發布到產品環境的代碼」,以master為中心保持一致的合併方向,不然分支之間亂合併就很難管理了。

目前有一個缺陷是持續集成環境只對master進行測試,理想的情況下應該建立一個staging的分支,持續集成環境也要對staging分支進行測試。

推薦閱讀:

如何在mac下遠程搭建git伺服器?
【GIT技巧】清除歷史記錄中的敏感信息
gitlab 與walle配合搭建,無法檢測,請教一下這個是什麼原因?

TAG:Git |