代碼迭代管理，怎樣做比較好？

代碼管理，常用的工具有Git和Svn。Git更強大，但是使用起來更復(fù)雜。Svn，功能比較簡單，出問題的概率比較高，但是用起來比較簡單。

在管理工具的選擇上，我個人建議小團隊選擇svn，因為小團隊其實不不需要太多功能，svn操作更適合小團隊。如果團隊很大，或者項目由多個團隊協(xié)同，Git是合適的，可以集成更多的功能，規(guī)范管理，進行代碼評審。

在具體的管理方法上，需要控制每一個迭代、版本和分支。因為研發(fā)的勞動力成本很高。ampd人員，我們不可能留住研發(fā)人員。amp人員長期閑置。所以在大多數(shù)情況下，我們的Rampamp步驟將是:

1.Rampampd組開始開發(fā)版本a。

2.A版提升測試

3.測試開始測試版本A，Rampampd人員繼續(xù)開發(fā)b版本。

4.版本A找到bug并修復(fù)。

5.版本A的發(fā)布

然后繼續(xù)執(zhí)行這個循環(huán)。在這個過程中，Rampampd人員需要同時修改A版和B版，不能互相影響。這不僅需要代碼管理的工具，還需要管理方法。

無論在任何源代碼管理工具中，我們都有兩個代碼版本:主干和分支，就像一棵樹的主干和分支一樣。主干作為一個持續(xù)開發(fā)的版本存在，而分支的存在是為了在當(dāng)前狀態(tài)下維護一個版本。

因此:

1.我們的研發(fā)；ampd組在開發(fā)A版，在主干上完成；

2.Rampampd團隊養(yǎng)版本A，是我們需要建立一個當(dāng)前骨干的分支；

3.測試A版的測試，繼續(xù)B版的研發(fā)，也就是骨干改B版的版本；

4.測試中發(fā)現(xiàn)了A版本的Bug，需要修復(fù)分支版本的Bug，開發(fā)修復(fù)時將代碼合并到主干中；

5.發(fā)布版本A，然后凍結(jié)版本A對應(yīng)的分支版本。

因此，在整個研發(fā)過程中。ampd迭代，會有一個版本不斷變化的主干和一個可能有小版本變化的分支。

一個主干可以有幾個分支，這是一個連續(xù)的過程，分支也可以有分支。比如當(dāng)我們需要迭代一個分支版本的時候，這個分支會有和主干一樣的流程，它會繼續(xù)迭代，測試，發(fā)布。

當(dāng)然，這只是一個非常簡單的版本管理場景，在我們的實際工作中會復(fù)雜很多。我遇到過一個極端的情況，就是我們在做1.4版本的研發(fā)的時候，也在做2.0版本的研發(fā)。1.4作為一個分支，它不斷的生產(chǎn)它的分支1.4.1，1.4.2，甚至到1.5版本，以2.0為骨干，不斷的進行研發(fā)。

當(dāng)我們的2.0版完成后。到了80%的時候，由于種種原因，這個版本被放棄了，我們直接在1.5版本的基礎(chǔ)上開發(fā)了3.0版本。

這時候我們廢棄的2.0從樹干變成了樹枝，被凍住了。原來的1.5版本從分支變成了主干迭代其他小分支版本和3.0版本。這些情況都需要在實際工作中按照代碼管理的思路來控制。一旦他們控制不好，某個版本的源代碼可能會丟失，這將導(dǎo)致在穩(wěn)定版本上修復(fù)一個小Bug的成本，并且可能存在不可預(yù)知的風(fēng)險。

所以，唐不要對代碼管理漠不關(guān)心。

北京，黑馬、尚硅谷、千鋒軟件培訓(xùn)，哪個好一點？

總的來說，我感覺還是在硅谷比較好，在師資、口碑、課程方面都比較好。

當(dāng)然，每個人的評價標(biāo)準(zhǔn)不一樣，關(guān)注的點也不一樣，所以你也可以自己做一個多方面的調(diào)查。畢竟有些東西只有自己才能感受到。

至于老師和口碑，可以去官網(wǎng)或者一些問答類的知識平臺看看，比較容易。至于課程，可以去各大培訓(xùn)機構(gòu)官網(wǎng)下載，有自己的學(xué)習(xí)心得。當(dāng)然，它如果你沒有，那是一樣的。;我不想把它下載到嗶哩嗶哩。

還有教學(xué)環(huán)境、班級氛圍這類東西，需要你去校園實地考察了解。