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

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

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

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

1.Rampampd組開始開發版本a。

2.A版提升測試

3.測試開始測試版本A，Rampampd人員繼續開發b版本。

4.版本A找到bug并修復。

5.版本A的發布

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

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

因此:

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

2.Rampampd團隊養版本A，是我們需要建立一個當前骨干的分支；

3.測試A版的測試，繼續B版的研發，也就是骨干改B版的版本；

4.測試中發現了A版本的Bug，需要修復分支版本的Bug，開發修復時將代碼合并到主干中；

5.發布版本A，然后凍結版本A對應的分支版本。

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

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

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

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

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

所以，唐不要對代碼管理漠不關心。

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

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

當然，每個人的評價標準不一樣，關注的點也不一樣，所以你也可以自己做一個多方面的調查。畢竟有些東西只有自己才能感受到。

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

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