很多产品经理可能一直以来有这样一个疑问，这么多程序猿是怎么在一起撸代码的啊？

听起来，第三种方法比较靠谱，可是我们还需要依靠一个强大的文件版本管理工具才可以实现哦，这个就是svn。在开始协同撸代码前，需要在一个公共的主机上搭建svn的服务器，然后如同大厦奠基般需要创建一个svn的目录，自此，所有程序猿写的代码都需要提交到这个svn的目录上面，同时，所有程序员的代码修改都要以svn服务器上的代码为基准。

程序猿在svn上撸代码时有三个重要操作：更新，编辑冲突，提交。首先程序猿将服务器上的最新代码更新到本地，然后以此代码为基准在本地开始进行自己的修改，当自己修改的比较满意后，会想要将这些本地的修改提交到服务器上，但是由于修改的这段时间，别的程序猿也可能提交了一些代码，所以需要再次更新一下，看看这段时间别人修改的代码和自己修改的部分有没有冲突，这里svn提供了差异比对的功能，如果有相同部分的代码被修改了，svn就会在更新的时候给出提示，需要程序猿对这些代码修改冲突的地方进行检查并再次修改保证没有冲突后，才可以提交代码。（代码提交高峰期可能出现一提交就冲突，刚修改完冲突，一提交又冲突，这个才郁闷啊）

有的程序猿比较懒，会跳过更新，编辑冲突，直接进行提交，如果运气好，提交的文件在这段时间别人都没有修改过，那么就没有冲突，可以提交成功。但是如果提交的时候svn进行比对发现有文件被别人修改过了，这个时候会强制提醒程序猿走一次更新，编辑冲突的流程。一旦提交成功，svn服务器便会详细记录此次提交，并递增的分配一个版本号。

这里看到，svn有两个重要的功能，文件提交记录和文件修改比对。

程序猿们在协同编码的时候也会发生一些有趣的事情。一个人写代码会有bug，几个人同时写代码那就更容易出bug了，这样就会产生bug纠纷，就好比程序代码被轮x了，怀孕了，现在要找父亲了，可父亲是谁呢？被列为嫌疑犯的程序猿肯定都不希望孩子是自己的，不免会互相争论一番。传统解决方法就是慢慢调试，找到产生bug的相关代码，然后让写bug的程序猿去修复。但是让谁去调试bug呢，毕竟耗时又耗力？有人愿意担当还好，如果都觉得bug不是自己的不愿意去查bug，就又会陷入僵持了。这个时候svn就派上用场了：进行代码回退。svn服务器因为详细记录了每次提交，所以它可以完整的回退到任意一个版本上，那么就可以不断向前回退提交，然后运行程序，就可以找到究竟是哪次提交产生了这个bug，从而确认是哪个程序猿搞出来的bug。

同时根据这个理论，产生了bug追责究极大法-svn二分法，据说被此法追责到的程序猿能绕地球一圈。怎么操作呢？例如回退到版本号100上没有这个bug，回退到版本号200上有这个bug，那么就回退到版本号150上看看有没有这个bug，如果有就继续查版本号125，没有就查版本号175，以此类推，不断缩小追查区间，最终一定能确定到某一个版本号对应提交产生了这个bug，只要看看这个版本是谁提交的可以知道是谁的bug了。（当然svn的功能可不仅仅是这些哦，有兴趣的可以详细把玩一下）

古代妃子侍寝的时候都会有太监记录，这样日后怀孕了也可以推断出是不是皇帝的。

历史总是惊人的相似…