iOS里的Git版本管理方法

Git和SVN是我們代碼開發(fā)中,最常用的兩款代碼管理軟件。在這里我來寫寫我在工作中如何使用Git來管理我們的代碼開發(fā)。

首先,我們是一個多人開發(fā)的團(tuán)隊(duì),因此在開發(fā)過程中,少不了要進(jìn)行多人協(xié)作的時候。不同的功能分支就成了家常便飯的事情了。咱先來看一副圖:

GitFlow.png

這幅圖里畫的是我日常工作中,代碼管理中Git分支的存在形式。從最上層的一行中可以看到,一般會存在一些這樣的分支:
>>Master: 主分支;主要是穩(wěn)定的版本分支,正式發(fā)布的版本都從Master拉。
>>Develop: 開發(fā)分支;更新和變動最頻繁的分支,正常情況下開發(fā)都是在Develop分支上進(jìn)行的。
>>Release:預(yù)發(fā)行分支;一般來說,代表一個版本的功能全部開發(fā)完成后遞交測試,測試出Bug后進(jìn)行修復(fù)的分支。
>>Features: 功能分支; 其實(shí)Features不是一個分支,而是一個分支文件夾。里面包含了每個程序員開發(fā)的功能點(diǎn)。Feature開發(fā)完成后合入Develop分支。
>>HotFix: 最希望不會被創(chuàng)建的分支;這個分支的存在是在已經(jīng)正式上線的版本中,發(fā)現(xiàn)了重大Bug進(jìn)行修復(fù)的分支。

介紹完了幾個分支的主要功能,我們能談?wù)勔粋€具體的App軟件版本開發(fā)中的流程。

  1. 軟件版本的起點(diǎn):A

需求總是在不斷更新的。

上一次產(chǎn)品經(jīng)理需求0.1的軟件版本剛剛完成后,這不又來了新的版本需求0.2,這次一共兩個功能點(diǎn)。幸好我們有Git,讓并行開發(fā)成為可能。拉取Develop分支準(zhǔn)備開干!

  1. 開發(fā)的起點(diǎn):B

兩名工程師,兩個不同的需求,大師甲和大師乙各自領(lǐng)取一個功能點(diǎn)開干;從Develop拉取屬于自己的分支,有單獨(dú)的分支就不會被干擾:)

3、開發(fā)的終點(diǎn):H
??一周不到,兩位大師就已經(jīng)完成了屬于自己的功能;從圖上看,都有兩次代碼的提交。大師們各自開發(fā)的功能初步看似乎沒有啥問題,但是我們的App版本是一個多功能的集合,是否合在一起也會沒有問題?這時候大師們把屬于自己的分支合入Develop,并刪掉自己的工作Branche。編譯,運(yùn)行,Success!

4、預(yù)發(fā)行的起點(diǎn):Release 0.2 節(jié)點(diǎn)(I)
??大師們的能力果然與眾不同,合入后沒有一點(diǎn)問題,達(dá)到提交測試部的標(biāo)準(zhǔn)。新建Release 0.2 分支,代表一個里程碑式的事件。

5、Release 分支Bug宿命
??世上沒有哪個大師的代碼是沒有Bug的,大師甲和大師乙也不例外。這不,測試部剛拿到預(yù)發(fā)行的版本就曝出了2個Bug。
??不過沒有關(guān)系,能夠復(fù)現(xiàn)的Bug對于我們來說就不是Bug。從Release 0.2拉取Bug修復(fù)分支。修好了,繼續(xù)合進(jìn)Release 0.2。誰叫Release就是這樣的宿命呢。

6、版本發(fā)行的終點(diǎn): M
??但愿人長久,Bug不再有。
??經(jīng)過大師們艱苦卓絕的bug修復(fù),終于通過了測試部的測試,也得到了產(chǎn)品經(jīng)理們的認(rèn)可,準(zhǔn)備提交App Store審核。
??Release合入Master分支,打上Tag 0.2,這就是這次的MileStone了。
??當(dāng)然也得記得Release合入Develop,之前這么多的bug也得在Develop上修復(fù)修復(fù)不是。做好了這些,Release就可以刪啦。

7、救火隊(duì)員一般的HotFix: N
??好事多磨!AppStore剛發(fā)出去的App, 就有用戶反饋Crash! 大師甲和大師乙臨危受命!
??從Master拉取HotFix分支來搞定它。原來是數(shù)組越界!分分鐘搞定。完成后合入Master,版本更新為Tag 0.3,代表我們修復(fù)了重大問題。編譯,運(yùn)行,沒問題,提交App Store等審核。
??噢,one more thing, HotFix 也要合入Develop,又多了一個功能點(diǎn)(bug修復(fù))不是。

8、新的輪回開始:P
??1-> 7就是一個版本的開發(fā)過程中,我們的Git Flow流。到了最后,P和O節(jié)點(diǎn)擁有了相同的內(nèi)容,就像在一開始的A和B那樣。
??這時候,我看見產(chǎn)品經(jīng)理又拿著版本需求1.0向我走來......

參考:

  1. http://nvie.com/posts/a-successful-git-branching-model/
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容