轉載:http://blog.csdn.net/victor_barnett/article/details/51211282
這幾天看詳細了一下Git Flow的模型介紹,感覺“很好很強大”,這個開發模型利用Git的易於分支和合並的特點,能夠比較容易地將開發、發布、部署、bug修復分隔開來。
正准備在自己的團隊內部推廣使用,比較擔心的是管理工作稍微繁瑣一點。操作倒不復雜,只是需要頭腦清醒,熟悉不同分支間的派生、合並關系和時機。沒想到“正在瞌睡的時候送來了一個枕頭”,正在使用的SourceTree工具天然支持Git Flow,而且把這個模型的各種操作通過菜單命令的形式提供了出來,大大減輕了使用人員的學習使用成本。
為了能讓大家少走彎路,也便於我盡快熟練使用,我進行了摸索和實踐,下面把具體的使用方式記錄下來供參考。
入口
SourceTree界面頂部的工具欄按鈕,從右至左第二個“GIT工作流”圖標就是。
初始化
為了便於展示,我在自己的一個Github項目上進行相關的操作。進入這個項目,然后點擊剛剛的“GIT工作流”工具欄按鈕。
建議不用做任何改動,直接“確定”即可。SourceTree會自動化進行一些操作,最明顯的變化是項目代碼庫里自動增加了一個develop的分支。
將新創建的develop分支推送到遠端倉庫。
我們到Github里看這個項目的分支關系圖如下:
從此,代碼庫里就存在了兩個永久性的分支:master和develop,未來所有的開發工作都圍繞這兩個分支進行派生跟合並。派生和合並的時機、源分支、目標分支跟具體的開發類型有關,Gitflow里有明確的規則,如果純粹使用命令行工具的話,需要牢記這些規則並正確執行。而SourceTree則把這些規則用具體功能自動化實現了,這樣就能減少人為的失誤,至少在我剛開始手動完成這些操作的時候,失誤的幾率還是挺高的。
從初始化的第一個界面中,還有三類分支的命名規則:feature、release、hotfix,這就是未來承接具體開發工作的分支類型,從名稱中就能准確把握他們的用途。
創建分支
上面提到,項目里有兩個永久的分支:master和develop。這兩個分支也被稱為“歷史性”分支,在其后的開發工作中,Gitflow模型支持在feature、release、hotfix分支上折騰,這樣也有效避免了不同類型的開發工作在代碼層級的耦合和干擾。
這三個分支的用途、派生來源分支和合並目標分支如下:
feature,功能開發分支,用於承接具體功能需求的開發
- 派生於develop
- 合並於develop
hotfix,bug修復分支,用於解決線上運行環境發現的bug
- 派生於master
- 合並於master、develop
release,版本發布分支,用於完成發布准備的
- 派生於develop
- 合並於master、develop
跟“歷史性”分支相反,這三類分支都是短期分支,針對他們的工作內容完成后,一般都要進行刪除。工作內容完成的標識有兩個:開發完成、合並完成,缺一不可。
hotfix
正式環境正在運行的項目發現了一個bug,需要創建hotfix分支進行bug修復,在已經做過Gitflow初始化的項目上點擊工具欄上的“Gitflow”按鈕,出現如下窗口:
但有時候我們已經在庫里創建了一個還未完成的分支,就會看到這個窗口:
點擊“建立新的修復補丁”:
輸入自己想要的分支名稱,“確定”即可創建,從預覽圖中可以看到分支派生來源以及派生出來的分支信息。這里有一點要注意,hotfix分支的名稱在最終合並到master時會自動變成標簽,而一般來說,master的標簽往往標識版本號,比如1.0.0,所以這個分值名稱最好能夠按照版本規則來命名,比如1.0.1。
hotfix分支創建完成后,在分支目錄結構里能夠看到它:
經過一系列艱苦卓越的工作,這個bug修復完成了,就要合並到master和develop,在SourceTree里,只要通過點擊“Gitflow”工具欄即可指導你完成:
點擊第一個“完成修復補丁”:
這個操作默認“刪除分支”,將把本地的修復分支刪除掉,因為它的使命已經完成。合並時如果出現沖突,還是需要開發人員自行解決的。這時能夠在“預覽”位置看到這個hotfix分支的合並關系示意圖。
合並后將代碼庫推送到遠端,這時在Github上可以看到這些分支的關聯關系:
中間的藍色分支既是這個hotfix分支,從圖中可以看到這個分支先后被合並到了master和develop上。因為我沒有把這個分支提交到Github,所以只有圖形示意,沒有類似master和develop的名稱指示。
feature
當接到具體的功能需求時,開發人員需要派生feature分支,在SourceTree上,派生的工作相當簡單,只要在已經做過Gitflow初始化的項目上點擊工具欄上的“Gitflow”按鈕,出現如下窗口:
點擊第一個按鈕“建立新的功能”:
這里,“功能名稱”的值不像hotfix分支那樣需要考慮發布版本號的規則,可以用能夠清晰描述功能特征的文字。
創建完成后,SourceTree的項目目錄樹就出現了這個新分支,如下:
現在就可以在這個分支上修修補補了,經過一系列艱苦卓越的工作,這個功能開發完成了,就要合並到develop。功能分支只能合並到develop,為新的release分支做准備,
在SourceTree里,只要通過點擊“Gitflow”工具欄即可指導你完成:
“刪除分支”和“預覽”和上面hotfix分支里提到的效果是一樣,所不同的是,這里沒有“推送變更到遠程倉庫”的選項。有沒有這個選項的差別不大,可能是為了體現分支的推進的緊急程度吧。
合並完成后並將本地庫推送到遠端Github,這時看Github的分支關系網絡圖如下:
因為我在做的這個示例操作的時候,並沒有再對master分支進行過派生和合並,所以看到master的指示停在原地,后面並入develop的黑色分支既是功能分支。
release
所有特性的開發工作都是為了產品功能的更替,當一個或多個特性開發完成,可以進行發布了,就要准備創建release分支。
Release分支是為上線做准備的,它的命名也要遵守項目的版本命名規則,這個名字在最終合並到master時會自動變成版本標簽。
這個release分支也是測試工作的目標對象,,經過一系列艱苦卓越的測試、調整工作,這個release完成了,達到了可上線的狀態,就要合並到master和develop。
如圖“預覽”所示,這個release的名稱會自動成為master的標簽。
這一次,我有意沒有刪除這個分支,並把它推送到了Github,在Github上的分支關系網絡圖中,能夠明確地看到release的起點和終點,它最終被合並到了兩個“歷史性”分支中了。
收尾
三類臨時性分支中,hotfix和release的結果都要合並到master和develop中,為什么?因為它們的修改結果持續影響這后續的開發和維護,必須合並以保證代碼的一致性。
至此,SoureTree的Gitflow應用教程已經完成,如果你沒有認識到這個特性很有用,我只能說:好吧,你的開發工作還沒有復雜到一個程度,一個必須要規避代碼干擾、保證並行推進的程度。
對於小型項目和團隊來說,基於GIT的中心式協作模型和特性分支模型就足夠了;本協作模型適合中型、大型項目和團隊;對於更大型的團隊和項目來說,除了這個協作模型,還有一個交叉型協作模型可供管理使用。