從0開始學(xué)習(xí) GitHub 系列之「06.團隊合作利器 Branch」
Git 相比于 SVN 最強大的一個地方就在于「分支」,Git 的分支操作簡直不要太方便,而實際項目開發(fā)中團隊合作最依賴的莫過于分支了,關(guān)于分支前面的系列也提到過,但是本篇會詳細講述什么是分支、分支的具體操作以及實際項目開發(fā)中到底是怎么依賴分支來進行團隊合作的。
本文引用地址:http://butianyuan.cn/article/201705/358889.htm1. 什么是分支?
我知道讀者中肯定有些人對分支這個概念比較模糊,其實你們可以這么理解,你們幾個人一起去旅行,中間走到一個三岔口,每條路可能有不同的風(fēng)景,你們約定 3 天之后在某地匯聚,然后各自出發(fā)了。而這三條分叉路就可以理解成你們各自的分支,而等你們匯聚的時候相當(dāng)于把你們的分支進行了合并。
2. 分支的常用操作
通常我們默認都會有一個主分支叫 master ,下面我們先來看下關(guān)于分支的一些基本操作:
新建一個叫 develop 的分支
git branch develop
這里稍微提醒下大家,新建分支的命令是基于當(dāng)前所在分支的基礎(chǔ)上進行的,即以上是基于 mater 分支新建了一個叫做 develop 的分支,此時 develop 分支跟 master 分支的內(nèi)容完全一樣。如果你有 A、B、C三個分支,三個分支是三位同學(xué)的,各分支內(nèi)容不一樣,如果你當(dāng)前是在 B 分支,如果執(zhí)行新建分支命令,則新建的分支內(nèi)容跟 B 分支是一樣的,同理如果當(dāng)前所在是 C 分支,那就是基于 C 分支基礎(chǔ)上新建的分支。
切換到 develop 分支
git checkout develop
如果把以上兩步合并,即新建并且自動切換到 develop 分支:
git checkout -b develop
把 develop 分支推送到遠程倉庫
git push origin develop
如果你遠程的分支想取名叫 develop2 ,那執(zhí)行以下代碼:
git push origin develop:develop2
但是強烈不建議這樣,這會導(dǎo)致很混亂,很難管理,所以建議本地分支跟遠程分支名要保持一致。
查看本地分支列表
git branch
查看遠程分支列表
git branch -r
刪除本地分支
git branch -d develop
git branch -D develop (強制刪除)
刪除遠程分支
git push origin :develop
如果遠程分支有個 develop ,而本地沒有,你想把遠程的 develop 分支遷到本地:
git checkout develop origin/develop
同樣的把遠程分支遷到本地順便切換到該分支:
git checkout -b develop origin/develop
3. 基本的團隊協(xié)作流程
一般來說,如果你是一個人開發(fā),可能只需要 master、develop 兩個分支就 ok 了,平時開發(fā)在 develop 分支進行,開發(fā)完成之后,發(fā)布之前合并到 master 分支,這個流程沒啥大問題。
如果你是 3、5 個人,那就不一樣了,有人說也沒多大問題啊,直接可以新建 A、B、C 三個人的分支啊,每人各自開發(fā)各自的分支,然后開發(fā)完成之后再逐步合并到 master 分支。然而現(xiàn)實卻是,你正在某個分支開發(fā)某個功能呢,這時候突然發(fā)現(xiàn)線上有一個很嚴(yán)重的 bug ,不得不停下手頭的工作優(yōu)先處理 bug ,而且很多時候多人協(xié)作下如果沒有一個規(guī)范,很容易產(chǎn)生問題,所以多人協(xié)作下的分支管理規(guī)范很重要,就跟代碼規(guī)范一樣重要,以下就跟大家推薦一種我們內(nèi)部在使用的一種分支管理流程 Git Flow。
4. Git Flow
準(zhǔn)確的說 Git Flow 是一種比較成熟的分支管理流程,我們先看一張圖能清晰的描述他整個的工作流程:
第一次看上面那個圖是不是一臉懵逼?跟我當(dāng)時一樣,不急,我來用簡單的話給你們解釋下。
一般開發(fā)來說,大部分情況下都會擁有兩個分支 master 和 develop,他們的職責(zé)分別是:
master:永遠處在即將發(fā)布(production-ready)狀態(tài)
develop:最新的開發(fā)狀態(tài)
確切的說 master、develop 分支大部分情況下都會保持一致,只有在上線前的測試階段 develop 比 master 的代碼要多,一旦測試沒問題,準(zhǔn)備發(fā)布了,這時候會將 develop 合并到 master 上。
但是我們發(fā)布之后又會進行下一版本的功能開發(fā),開發(fā)中間可能又會遇到需要緊急修復(fù) bug ,一個功能開發(fā)完成之后突然需求變動了等情況,所以 Git Flow 除了以上 master 和 develop 兩個主要分支以外,還提出了以下三個輔助分支:
feature: 開發(fā)新功能的分支, 基于 develop, 完成后 merge 回 develop
release: 準(zhǔn)備要發(fā)布版本的分支, 用來修復(fù) bug,基于 develop,完成后 merge 回 develop 和 master
hotfix: 修復(fù) master 上的問題, 等不及 release 版本就必須馬上上線. 基于 master, 完成后 merge 回 master 和 develop
什么意思呢?
舉個例子,假設(shè)我們已經(jīng)有 master 和 develop 兩個分支了,這個時候我們準(zhǔn)備做一個功能 A,第一步我們要做的,就是基于 develop 分支新建個分支:
git branch feature/A
看到了吧,其實就是一個規(guī)范,規(guī)定了所有開發(fā)的功能分支都以 feature 為前綴。
但是這個時候做著做著發(fā)現(xiàn)線上有一個緊急的 bug 需要修復(fù),那趕緊停下手頭的工作,立刻切換到 master 分支,然后再此基礎(chǔ)上新建一個分支:
git branch hotfix/B
代表新建了一個緊急修復(fù)分支,修復(fù)完成之后直接合并到 develop 和 master ,然后發(fā)布。
然后再切回我們的 feature/A 分支繼續(xù)著我們的開發(fā),如果開發(fā)完了,那么合并回 develop 分支,然后在 develop 分支屬于測試環(huán)境,跟后端對接并且測試的差不多了,感覺可以發(fā)布到正式環(huán)境了,這個時候再新建一個 release 分支:
git branch release/1.0
這個時候所有的 api、數(shù)據(jù)等都是正式環(huán)境,然后在這個分支上進行最后的測試,發(fā)現(xiàn) bug 直接進行修改,直到測試 ok 達到了發(fā)布的標(biāo)準(zhǔn),最后把該分支合并到 develop 和 master 然后進行發(fā)布。
以上就是 Git Flow 的概念與大概流程,看起來很復(fù)雜,但是對于人數(shù)比較多的團隊協(xié)作現(xiàn)實開發(fā)中確實會遇到這么復(fù)雜的情況,是目前很流行的一套分支管理流程,但是有人會問每次都要各種操作,合并來合并去,有點麻煩,哈哈,這點 Git Flow 早就想到了,為此還專門推出了一個 Git Flow 的工具,并且是開源的:
GitHub 開源地址:https://github.com/nvie/gitflow
簡單點來說,就是這個工具幫我們省下了很多步驟,比如我們當(dāng)前處于 master 分支,如果想要開發(fā)一個新的功能,第一步切換到 develop 分支,第二步新建一個以 feature 開頭的分支名,有了 Git Flow 直接如下操作完成了:
git flow feature start A
這個分支完成之后,需要合并到 develop 分支,然而直接進行如下操作就行:
git flow feature finish A
如果是 hotfix 或者 release 分支甚至?xí)詣訋湍愫喜⒌?develop、master 兩個分支。
想必大家已經(jīng)了解了這個工具的具體作用,具體安裝與用法我就不多提了,感興趣的可以看我下我之前寫過的一篇博客:
http://stormzhang.com/git/2014/01/29/git-flow/
5. 總結(jié)
以上就是我分享給你們的關(guān)于分支的所有知識,一個人你也許感受不到什么,但是實際工作中大都以團隊協(xié)作為主,而分支是團隊協(xié)作必備技能,而 Git Flow 是我推薦給你們的一個很流行的分支管理流程,也是我們薄荷團隊內(nèi)部一直在實踐的一套流程,希望對你們有借鑒意義。
評論