十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
這篇文章給大家介紹Git版本思路是什么,內(nèi)容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
成都創(chuàng)新互聯(lián)公司專注于愛民企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站建設(shè),成都商城網(wǎng)站開發(fā)。愛民網(wǎng)站建設(shè)公司,為愛民等地區(qū)提供建站服務(wù)。全流程按需策劃,專業(yè)設(shè)計,全程項目跟蹤,成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)
簡單的說,git的管理策略目前有兩大流派。平時和同事聊天或和別的公司的朋友交流時也能夠感覺的到,即Git One Track和Git-flow。?
一個軌道?
One Track簡單的說,就是整個團隊在開發(fā)項目時都在同一個分支上進行。這也就意味著開發(fā)階段的所有工作都集中在同一個分支,例如新功能開發(fā)、bug的修復(fù)。當(dāng)然,One Track策略并不意味著只有一個分支,而是只有一個開發(fā)分支。當(dāng)達到團隊設(shè)定的里程碑時,可以開一個新的分支用來維護這個基本穩(wěn)定的版本,這個維護分支只進行維護的工作,而不進行開發(fā)的工作。同時,開發(fā)分支繼續(xù)進行最新的開發(fā)工作。?
使用這種策略的最大特點就是大家都在同一個分支上工作,因此每次提交代碼都有可能會有沖突。為了減少沖突,團隊也常常會提高提交的頻率,同時每次提交的顆粒度都比較小。同時,管理成本比較低,整個團隊的學(xué)習(xí)成本也比較低。?
在我之前的項目中,參與過一個剛從svn切換到git的團隊,我們使用過一段時間One Track的工作方式,可以看到這種策略對整個團隊接觸和適應(yīng)git還是很有好處的。?
但是我相信更多的人還是更推崇另外一種策略,即Git-Flow策略。?
gitflow?
首先我相信很多人一定在哪里會見過下面這張圖: ?
這張圖已經(jīng)能很好的說明了gitflow了。即任何變更都是一個分支。?
可以看到,這張圖中的分支雖然很多,但是大體上可以分為兩類。即主要分支和輔助分支。?
主要分支?
主要分支即git默認的mater分支以及一個主開發(fā)分支develop。?
master分支是git默認的主分支,平時團隊不在該分支上進行開發(fā)。而主開發(fā)分支develop則管理著開發(fā)人員提交的代碼,當(dāng)代碼穩(wěn)定時或固定一個周期,將develop分支上的代碼合并到主分支。?
輔助部門?
輔助分支是團隊每個開發(fā)人員都能接觸到的,常見的輔助分支包括:?
? 功能科?
? 出版公司?
? 修理分公司?
這三類分支都有其對應(yīng)的使用場景。?
開發(fā)新的功能時,需要從主開發(fā)分支上創(chuàng)建一個新的功能分支,待該分支上的功能開發(fā)完畢之后,再合并會主功能分支。?
發(fā)布分支則是在版本發(fā)布時創(chuàng)建的分支, 按照產(chǎn)品里程碑的需求包括應(yīng)該完成的功能。?
修復(fù)分支則是當(dāng)出現(xiàn)bug時,為了不影響開發(fā)分支,因此創(chuàng)建出一個新的分支來修改bug,之后再合并回開發(fā)分支。?
因此我們可以看到,GitFlow的策略無論是開發(fā)功能還是修復(fù)bug都是以分支的方式來進行。這樣做的好處當(dāng)然是管理上十分干凈。但是由于功能開發(fā)時間相對要長、代碼提交的粒度相對較大,因此在分支合并的時候有可能會出現(xiàn)沖突的問題,另外一個問題是對整個團隊的要求要比One Track策略大。?
不過,并沒有最完美的方案,有的也僅僅是更適合團隊的方案。例如很多團隊包括我現(xiàn)在都更喜歡將兩種方式混合使用,例如針對One Track都在同一個分支上開發(fā),可能不夠干凈,我們就可以適當(dāng)?shù)拈_一個新的分支也用來開發(fā)。針對GitFlow提交合并時代碼粒度大、沖突多,我們就每天都同步一次代碼而不必等整個功能都完成再合并到主開發(fā)分支。?
關(guān)于Git版本思路是什么就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學(xué)到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。