Git分支管理之GitFlow的使用

在分享開始前...

  • Hello, World! I am Tristan. (特里斯譚)
  • 喜歡和優(yōu)秀的人做挑戰(zhàn)的事情
  • 崇尚自由與分享的互聯(lián)網(wǎng)精神
  • The most important thing: I have dream and passion
  • 2015年11月10日,在這個雙十一即將到來的時分,我做出了一個重要的決定,就是開始寫文章。
  • 作為一個技術團隊的負責人和一個標準的ScrumMaster,讓我來進入第一篇分享的話題 -- GitFlow

關于Git的一段話

目前在開源技術社區(qū),Git作為版本控制工具,正逐步取代SVN的地位。Git對分布式開發(fā),分支開發(fā)等有更好的支持,也更容易在各個開發(fā)分支上及時反應主干的最新更新,避免SVN在最后提交分支代碼時發(fā)現(xiàn)和主干代碼差別太大難以merge成功。但是Git的學習成本較高,如何和網(wǎng)站開發(fā)流程相結合還缺乏最佳實踐和使用規(guī)范。不過相信Git成為網(wǎng)站的標準版本控制工具是遲早的。

——《大型網(wǎng)站技術架構》作者、原阿里巴巴技術專家 李智慧(2012年底)


猜猜下面幾個關鍵詞是什么

  • Tuesday, January 05, 2010
  • A successful Git branching model
  • http://nvie.com/
  • Vincent Driessen

GitFlow是什么

Git Flow是構建在Git之上的一個組織軟件開發(fā)活動的模型,是在Git之上構建的一項軟件開發(fā)最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行為規(guī)范和簡化部分Git操作的工具。

2010年1月,在一篇名為“一種成功的Git分支模型”的博文中,@nvie介紹了一種在Git之上的軟件開發(fā)模型。通過利用Git創(chuàng)建和管理分支的能力,為每個分支設定具有特定的含義名稱,并將軟件生命周期中的各類活動歸并到不同的分支上。實現(xiàn)了軟件開發(fā)過程不同操作的相互隔離。這種軟件開發(fā)的活動模型被nvie稱為“Git Flow”。

下面讓我們用一幅圖來了解GitFlow


Git-branching-model.png

Git Flow中的分支

Git Flow模型中定義了主分支和輔助分支兩類分支。其中主分支用于組織與軟件開發(fā)、部署相關的活動;輔助分支組織為了解決特定的問題而進行的各種開發(fā)活動。

主分支

主分支是所有開發(fā)活動的核心分支。所有的開發(fā)活動產(chǎn)生的輸出物最終都會反映到主分支的代碼中。主分支分為master分支和development分支。

main.png

1. master分支

master分支上存放的應該是隨時可供在生產(chǎn)環(huán)境中部署的代碼(Production Ready state)。當開發(fā)活動告一段落,產(chǎn)生了一份新的可供部署的代碼時,master分支上的代碼會被更新。同時,每一次更新,最好添加對應的版本號標簽(TAG)。

2. develop分支

develop分支是保存當前最新開發(fā)成果的分支。通常這個分支上的代碼也是可進行每日夜間發(fā)布的代碼(Nightly build)。因此這個分支有時也可以被稱作“integration branch”。

當develop分支上的代碼已實現(xiàn)了軟件需求說明書中所有的功能,通過了所有的測試后,并且代碼已經(jīng)足夠穩(wěn)定時,就可以將所有的開發(fā)成果合并回master分支了。對于master分支上的新提交的代碼建議都打上一個新的版本號標簽(TAG),供后續(xù)代碼跟蹤使用。

因此,每次將develop分支上的代碼合并回master分支時,我們都可以認為一個新的可供在生產(chǎn)環(huán)境中部署的版本就產(chǎn)生了。通常而言,“僅在發(fā)布新的可供部署的代碼時才更新master分支上的代碼”是推薦所有人都遵守的行為準則?;诖?,理論上說,每當有代碼提交到master分支時,我們可以使用Git Hook觸發(fā)軟件自動測試以及生產(chǎn)環(huán)境代碼的自動更新工作。這些自動化操作將有利于減少新代碼發(fā)布之后的一些事務性工作。

輔助分支

輔助分支是用于組織解決特定問題的各種軟件開發(fā)活動的分支。輔助分支主要用于組織軟件新功能的并行開發(fā)、簡化新功能開發(fā)代碼的跟蹤、輔助完成版本發(fā)布工作以及對生產(chǎn)代碼的缺陷進行緊急修復工作。這些分支與主分支不同,通常只會在有限的時間范圍內(nèi)存在。

輔助分支包括:

  • 用于開發(fā)新功能時所使用的feature分支;
  • 用于輔助版本發(fā)布的release分支;
  • 用于修正生產(chǎn)代碼中的缺陷的hotfix分支。

以上這些分支都有固定的使用目的和分支操作限制。從單純技術的角度說,這些分支與Git其他分支并沒有什么區(qū)別,但通過命名,我們定義了使用這些分支的方法。

1. feature分支

使用規(guī)范:

可以從develop分支發(fā)起feature分支
代碼必須合并回develop分支
feature分支的命名可以使用除master,develop,release-,hotfix-之外的任何名稱
feature分支(有時也可以被叫做“topic分支”)通常是在開發(fā)一項新的軟件功能的時候使用,這個分支上的代碼變更最終合并回develop分支或者干脆被拋棄掉(例如實驗性且效果不好的代碼變更)。

一般而言,feature分支代碼可以保存在開發(fā)者自己的代碼庫中而不強制提交到主代碼庫里。

feaure.png

2. release分支

使用規(guī)范:

可以從develop分支派生
必須合并回develop分支和master分支
分支命名慣例:release-*
release分支是為發(fā)布新的產(chǎn)品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、準備發(fā)布版本所需的各項說明信息(版本號、發(fā)布時間、編譯時間等等)。通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交,進入新的軟件開發(fā)迭代周期。

當develop分支上的代碼已經(jīng)包含了所有即將發(fā)布的版本中所計劃包含的軟件功能,并且已通過所有測試時,我們就可以考慮準備創(chuàng)建release分支了。而所有在當前即將發(fā)布的版本之外的業(yè)務需求一定要確保不能混到release分支之內(nèi)(避免由此引入一些不可控的系統(tǒng)缺陷)。

成功的派生了release分支,并被賦予版本號之后,develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在當前即將發(fā)布的版本之后發(fā)布的版本。版本號的命名可以依據(jù)項目定義的版本號命名規(guī)則進行。

3. hotfix分支

使用規(guī)范:

可以從master分支派生
必須合并回master分支和develop分支
分支命名慣例:hotfix-*
除了是計劃外創(chuàng)建的以外,hotfix分支與release分支十分相似:都可以產(chǎn)生一個新的可供在生產(chǎn)環(huán)境部署的軟件版本。

當生產(chǎn)環(huán)境中的軟件遇到了異常情況或者發(fā)現(xiàn)了嚴重到必須立即修復的軟件缺陷的時候,就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工作。

這樣做的顯而易見的好處是不會打斷正在進行的develop分支的開發(fā)工作,能夠讓團隊中負責新功能開發(fā)的人與負責代碼緊急修復的人并行的開展工作。

hotfix.png

再用另一張圖回顧GitFlow

git-flow-overview.jpg

更進一步

Git Flow開發(fā)模型從源代碼管理角度對通常意義上的軟件開發(fā)活動進行了約束。應該說,為我們的軟件開發(fā)提供了一個可供參考的管理模型。Git Flow開發(fā)模型讓nvie的開發(fā)代碼倉庫保持整潔,讓小組各個成員之間的開發(fā)相互隔離,能夠有效避免處于開發(fā)狀態(tài)中的代碼相互影響而導致的效率低下和混亂。

所謂模型,在不同的開發(fā)團隊,不同的文化,不同的項目背景情況下都有可能需要進行適當?shù)牟眉艋驍U充。祝各位好運!

PS:為了簡化使用Git Flow模型時Git指令的復雜性,nvie開發(fā)出了一套git增強指令集。可以運行于Windows、Linux、Unix和Mac操作系統(tǒng)之下。有興趣的同學可以去看看。

如何使用GitFlow

  • 命令行方式 (忽略,繁瑣,不推薦)

  • 使用可視化操作工具

使用SourceTree作為Git分支管理工具,默認集成了GitFlow可視化管理工具。推薦使用此方式進行分支管理。(注意:沒有初始化過GitFlow的工程首次需要進行GitFlow初始化,點擊一個按鈕即可)

注意:以下操作以Mac上的SourceTree作為示例,在Windows上界面顯示稍有差別,但是操作和功能基本一致

  1. 打開SourceTree主界面
open_branches@2x.png
  1. 點擊右上角的GitFlow按鈕
gitflow_button@2x.png
  1. 進如GitFlow分支管理菜單界面
gitflow_menu@2x.png
  • 代碼管理在團隊開發(fā)中的一些思考

  1. 極小的團隊(1-2個人)進行開發(fā)是否有必要使用GitFlow?

  2. 每次commit意味著什么?

  3. Git使用的技巧:如何合并提交,撤銷提交?

對團隊開發(fā)的幫助

  • 軟件開發(fā)是一門藝術,但是需要嚴謹、協(xié)作的態(tài)度。
  • 任何事情做的越專業(yè)就越會形成一套較為成熟的方法論。
  • 再優(yōu)秀的工程師在團隊中也要和共同的目標達成一致(敏捷宣言)。
  • 希望通過GitFlow可以指導團隊擁有更高效的代碼分支管理準則。
  • 示例:某開發(fā)團隊的 Git分支管理規(guī)范
    (未必是良好的典范,但是一個有效的輸出成果)

在分享后...(個人感悟)

  1. 相信堅持的力量,定期分享和總結會讓你的成長的更加堅實有力
  2. 感謝分享的精神,我一直以為互聯(lián)網(wǎng)的感動中國獎應該頒發(fā)給這些無私分享的人們

參考文章

  1. Git工作流指南
  2. A successful Git branching model
  3. 基于git的源代碼管理模型——git flow
  4. Getting Started – Git-Flow
最后編輯于
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容

  • 前言 大家好!在下游回來了!不啰嗦快進正題!本篇文章是面對剛開始接觸Git的新手,所講命令并不全,在文章結束會放入...
    老匡話Android閱讀 3,973評論 -2 18
  • [轉(zhuǎn)載]https://www.ibm.com/developerworks/cn/java/j-lo-git-m...
    張志_koen_zhang閱讀 2,455評論 0 2
  • Git 規(guī)范 所有使用了本規(guī)范的項目,必須嚴格規(guī)范操作,否則不予以合并代碼、提測、打包上線等后續(xù)操作。 基本要求 ...
    zgsddzwj閱讀 13,775評論 1 14
  • 多種多樣的工作流使得在項目中實施Git時變得難以選擇。這份教程提供了一個出發(fā)點,調(diào)查企業(yè)團隊最常見的Git工作流。...
    JSErik閱讀 4,483評論 2 8
  • 【國學漢字】 【詞語】暮飔 【讀音】mù sī 【釋義】晚風。 【出處】清·洪昇《長生殿·密誓》:“趁碧落無云滓,...
    年年有余_85d6閱讀 485評論 0 2