這篇文章給大家介紹Git版本思路是什么，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

成都創(chuàng)新互聯(lián)公司專注于愛(ài)民企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站建設(shè),成都商城網(wǎng)站開發(fā)。愛(ài)民網(wǎng)站建設(shè)公司,為愛(ài)民等地區(qū)提供建站服務(wù)。全流程按需策劃，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

簡(jiǎn)單的說(shuō)，git的管理策略目前有兩大流派。平時(shí)和同事聊天或和別的公司的朋友交流時(shí)也能夠感覺(jué)的到，即Git One Track和Git-flow。?

一個(gè)軌道?

One Track簡(jiǎn)單的說(shuō)，就是整個(gè)團(tuán)隊(duì)在開發(fā)項(xiàng)目時(shí)都在同一個(gè)分支上進(jìn)行。這也就意味著開發(fā)階段的所有工作都集中在同一個(gè)分支，例如新功能開發(fā)、bug的修復(fù)。當(dāng)然，One Track策略并不意味著只有一個(gè)分支，而是只有一個(gè)開發(fā)分支。當(dāng)達(dá)到團(tuán)隊(duì)設(shè)定的里程碑時(shí)，可以開一個(gè)新的分支用來(lái)維護(hù)這個(gè)基本穩(wěn)定的版本，這個(gè)維護(hù)分支只進(jìn)行維護(hù)的工作，而不進(jìn)行開發(fā)的工作。同時(shí)，開發(fā)分支繼續(xù)進(jìn)行最新的開發(fā)工作。?

使用這種策略的最大特點(diǎn)就是大家都在同一個(gè)分支上工作，因此每次提交代碼都有可能會(huì)有沖突。為了減少?zèng)_突，團(tuán)隊(duì)也常常會(huì)提高提交的頻率，同時(shí)每次提交的顆粒度都比較小。同時(shí)，管理成本比較低，整個(gè)團(tuán)隊(duì)的學(xué)習(xí)成本也比較低。?

在我之前的項(xiàng)目中，參與過(guò)一個(gè)剛從svn切換到git的團(tuán)隊(duì)，我們使用過(guò)一段時(shí)間One Track的工作方式，可以看到這種策略對(duì)整個(gè)團(tuán)隊(duì)接觸和適應(yīng)git還是很有好處的。?

但是我相信更多的人還是更推崇另外一種策略，即Git-Flow策略。?

gitflow?

首先我相信很多人一定在哪里會(huì)見(jiàn)過(guò)下面這張圖： ?

這張圖已經(jīng)能很好的說(shuō)明了gitflow了。即任何變更都是一個(gè)分支。?

可以看到，這張圖中的分支雖然很多，但是大體上可以分為兩類。即主要分支和輔助分支。?

主要分支?

主要分支即git默認(rèn)的mater分支以及一個(gè)主開發(fā)分支develop。?

master分支是git默認(rèn)的主分支，平時(shí)團(tuán)隊(duì)不在該分支上進(jìn)行開發(fā)。而主開發(fā)分支develop則管理著開發(fā)人員提交的代碼，當(dāng)代碼穩(wěn)定時(shí)或固定一個(gè)周期，將develop分支上的代碼合并到主分支。?

輔助部門?

輔助分支是團(tuán)隊(duì)每個(gè)開發(fā)人員都能接觸到的，常見(jiàn)的輔助分支包括：?

? 功能科?

? 出版公司?

? 修理分公司?

這三類分支都有其對(duì)應(yīng)的使用場(chǎng)景。?

開發(fā)新的功能時(shí)，需要從主開發(fā)分支上創(chuàng)建一個(gè)新的功能分支，待該分支上的功能開發(fā)完畢之后，再合并會(huì)主功能分支。?

發(fā)布分支則是在版本發(fā)布時(shí)創(chuàng)建的分支， 按照產(chǎn)品里程碑的需求包括應(yīng)該完成的功能。?

修復(fù)分支則是當(dāng)出現(xiàn)bug時(shí)，為了不影響開發(fā)分支，因此創(chuàng)建出一個(gè)新的分支來(lái)修改bug，之后再合并回開發(fā)分支。?

因此我們可以看到，GitFlow的策略無(wú)論是開發(fā)功能還是修復(fù)bug都是以分支的方式來(lái)進(jìn)行。這樣做的好處當(dāng)然是管理上十分干凈。但是由于功能開發(fā)時(shí)間相對(duì)要長(zhǎng)、代碼提交的粒度相對(duì)較大，因此在分支合并的時(shí)候有可能會(huì)出現(xiàn)沖突的問(wèn)題，另外一個(gè)問(wèn)題是對(duì)整個(gè)團(tuán)隊(duì)的要求要比One Track策略大。?

不過(guò)，并沒(méi)有最完美的方案，有的也僅僅是更適合團(tuán)隊(duì)的方案。例如很多團(tuán)隊(duì)包括我現(xiàn)在都更喜歡將兩種方式混合使用，例如針對(duì)One Track都在同一個(gè)分支上開發(fā)，可能不夠干凈，我們就可以適當(dāng)?shù)拈_一個(gè)新的分支也用來(lái)開發(fā)。針對(duì)GitFlow提交合并時(shí)代碼粒度大、沖突多，我們就每天都同步一次代碼而不必等整個(gè)功能都完成再合并到主開發(fā)分支。?

關(guān)于Git版本思路是什么就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。