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这种老东西。
