A8SCFGN
代碼管理的話，常用的工具就是Git和Svn。Git的話，功能更強，不過使用上繁瑣一些。Svn的話，功能比較簡單，出問題的幾率也比較高，不過使用上比較簡單。
在管理工具上選擇的話，個人建議小團隊選擇svn，小團隊其實用不了太多的功能，svn操作方面，比較適合小團隊使用。如果團隊較大，或者項目是多個團隊協作的，Git合適一點，能夠集成更多的功能，管理上也規範一些，還能夠進行代碼的審查。
在具體的管理方法上，需要每個迭代分版本分支進行控制
由於研發人員的人力成本比較高，我們不可能讓研發人員長時間的閒置。所以大多數情況下，我們的研發步驟會是：
1. 研發團隊開始研發版本A
2. 版本A提測
3. 測試開始測試版本A，研發人員繼續研發版本B
4. 版本A發現Bug，對版本A進行修復
5. 版本A發佈
然後不停的執行這個循環。在這個過程中，研發人員需要同時修改版本A和版本B，並且相互之間還不能有所影響，這除了對代碼管理的工具有要求外，還需要在管理方式上有所規範。
不管在任何的源代碼管理工具中，我們都有主幹和分支兩種代碼版本，就好像是樹的樹幹和樹枝一樣。主幹是作為持續研發的版本存在的，而分支是為了維護當前某個狀態的版本存在的。
因此：
1. 我們研發團隊正在進行版本A的研發，這是在主幹上完成；
2. 研發團隊提測版本A，這是我們需要建立一個當前主幹的分支；
3. 測試進行版本A的測試，研發繼續版本B的研發，這是主幹的版本變成了版本B；
4. 測試發現了版本A的Bug，研發去修復，就需要對分支的版本進行Bug的修復，同時將代碼合併到主幹中；
5. 版本A發佈，這時凍結版本A所對應的分支版本。
於是，我們的整個研發迭代過程中，就會有一個一直持續變化版本的主幹，和一個可能出現小版本變化的分支。
一個主幹可以有若干個分支，這時一個不停持續的過程，而分支也可以有分支，例如：我們在某個分支版本上需要進行迭代的需求時，這個分支就會發生和主幹一樣的過程，進行持續的迭代和提測、發佈。
當然，這只是一個非常單純的版本管理場景，我們實際的工作中，會比這個複雜得多。我遇到過一個極端的情況，就是我們在做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的代價變得非常大，而且還可能出現不可預知的風險。
所以，別把代碼管理看得無所謂。
會技術的葛大爺
我覺得比較好的方式是用git來管理代碼。
說說我現在這個公司的代碼管理吧，一開始用的是以前的SVN管理的，SVN遇到的問題是有人把代碼直接替換掉，然後如果他提交替換的時候自己沒有確保這代碼已經沒有問題的話，等我們其他開發人員去下載的時候，有時會出現運行不了的情況，又要浪費時間去找bug.
還是用git好，我們公司用的是gitlab,用公司內網搭的，然後一般一個項目下建幾個分支，一個用來放開發環境代碼的，一個用來放測試環境代碼的，一個用來放生產環境代碼的。
開發人員提交代碼時，先提交到開發環境，然後開發環境的代碼確定沒有問題之後，才能合併給測試環境，最好測試環境測試代碼沒問題之後，才能合併給生產環境，這樣管理代碼可以保證至少生產環境的代碼是可以上線的。
總之，我還是建議用git來管理，不要用SVN這種老東西。
