公司的版本控制從svn遷移至git也有差不多快一個(gè)月了，每每在代碼合并 這個(gè)問(wèn)題上，屢屢會(huì)出出問(wèn)題，總結(jié)起來(lái)，自己在開發(fā)的時(shí)候，還是svn時(shí)代的那套思想，集中式版本控制，在分布式的路上還屬步履蹣跚。
根據(jù)阮一峰的日志--Git分支管理策略，作了一些總結(jié)。
目前對(duì)Git版本控制的使用， 并不是特別合理與順利，都是在熟悉中，最重要的還是接受分支開發(fā)這種理念，特別感謝偉大的林納斯·托瓦茲。
一、主分支Master
首先，代碼庫(kù)應(yīng)該有一個(gè)、且僅有一個(gè)主分支。所有提供給用戶使用的正式版本，都在這個(gè)主分支上發(fā)布。Git主分支的名字，默認(rèn)叫做Master。它是自動(dòng)建立的，版本庫(kù)初始化以后，默認(rèn)就是在主分支在進(jìn)行開發(fā)。
對(duì)于我們現(xiàn)在的開發(fā)流程來(lái)說(shuō)，這就是線上版本，線上版本應(yīng)該是bug最少化，代碼精簡(jiǎn)化。但就目前的開發(fā)流程而言，hotfix一天上好幾次，主版本一天也要更新好幾次，并不是很穩(wěn)定，不過(guò)這似乎是互聯(lián)網(wǎng)公司的通病。
二、開發(fā)分支Develop
主分支只用來(lái)分布重大版本，日常開發(fā)應(yīng)該在另一條分支上完成。我們把開發(fā)用的分支，叫做Develop。
這個(gè)版本其實(shí)有許多臟代碼，各種功能的試用，代碼的測(cè)試，都可以在這個(gè)版本上進(jìn)行。
就在Master分支上，對(duì)Develop分支進(jìn)行"合并"（merge）。
創(chuàng)建Develp的命令為：
git checkout -b develop master
# 切換到Master分支
git checkout master
# 對(duì)Develop分支進(jìn)行合并
git merge --no-ff develop
功能在Develop上開發(fā)，有需要合并到Mater，對(duì)于周期性的迭代功能，先拉個(gè)develop_v1,對(duì)于合作開發(fā)人員，每個(gè)人以develop_v1為基礎(chǔ)開自己的分支，開發(fā)自測(cè)好再合并一處由測(cè)試人員完成測(cè)試。
這里稍微解釋一下，上一條命令的--no-ff參數(shù)是什么意思。默認(rèn)情況下，Git執(zhí)行"快進(jìn)式合并"（fast-farward merge），會(huì)直接將Master分支指向Develop分支。
使用--no-ff參數(shù)后，會(huì)執(zhí)行正常合并，在Master分支上生成一個(gè)新節(jié)點(diǎn)。為了保證版本演進(jìn)的清晰，我們希望采用這種做法。
三、修補(bǔ)bug分支hotfix
最后一種是修補(bǔ)bug分支。軟件正式發(fā)布以后，難免會(huì)出現(xiàn)bug。這時(shí)就需要?jiǎng)?chuàng)建一個(gè)分支，進(jìn)行bug修補(bǔ)。
修補(bǔ)bug分支是從Master分支上面分出來(lái)的。修補(bǔ)結(jié)束以后，再合并進(jìn)Master和Develop分支。它的命名，可以采用hotfix-日期的形式。目前每天要上正式的代碼都是有的hotfix，大部分是bug修復(fù)，小部分是功能更新，這么也還算合理。
ps:(pycharm的代碼管理真的很好用哦-)
