使用svn的合理姿势

使用svn的合理姿势

何为合理的姿势

我将svn的使用指南起这样一个名字，是因为很多公司使用svn作为版本管理工具（虽然git更好用），可以说我们每天都在使用svn，但我们使用的真的合理吗。要回答这个问题，只需要问自己几个问题：

• 我们还在通过foo.c.bak的方式备份文件吗？
• 我们还在为“合版本”花费大量时间，而且叫苦连天吗？
• 我们还会有“xxx修改是xx个月之前的事情了，不记得为啥要改了”这样的说法吗？
• 我们还在通过即时聊天软件互相发送修改的文件吗？

如果答案是肯定的，那么我们就没有以合理的姿势使用svn，没有领会svn的精髓，姿势不正确，干活效率自然不高。为琐事分心，心情自然也不好。

所以我写这篇文章，旨在讨论一种使用svn的合理姿势，让svn的使用成为我们软件开发的一部分，成为我们血液里的东西，成为我们灵魂的一部分，而不是作为仅仅作为一个网盘。

分支的使用精髓

一般来说，一个svn的工程至少都会包括trunk和branch两个路径，一个用来存放主干版本，一个用来存放分支。

关于这两个目录的主流使用方式有两种：

1. 所有的开发都在trunk目录下进行，在需要开发新功能或有其他需求时进行branch，而branch出的新路径又类似于一个新的分支，大家关于新功能的开发都在这个新的分支下进行。
2. trunk目录只接受相对稳定的提交。每个人的工作都在自己的分支下进行，当一个功能相对稳定时再向trunk目录提交。

我个人来说是更倾向于第二种方式的，因为更有利于团队合作。第一种方式对于一个人的开发可能问题不大，两个人的开发如果软件架构设计的很好的话，应该也没什么问题，但如果参与开发的人多了，同时软件架构相对来说耦合性又较大的情况下，就要乱套了。

试想你正在修正代码库中一个令人头疼的bug，而你的同事正在开发一个新功能，而你们俩又都在同一个trunk目录下工作。那么你修复bug的过程中commit的代码可能会使代码库不能正常工作了，那么你的同事在update新代码后在你这不能正常工作的调试版本上开发新功能，发现出现各种莫名其妙的错误，最后发现原来是你上传了不能使用的代码，你俩就等着吵架吧。:)

那么你可能会说，我修正bug的过程中可以先不commit呀，等我测试成功了再commit，这样就不会影响同事新功能的开发了。恩，这么说也没错，但你不实时commit，而是等三个月后bug测试成功了再commit，那么你告诉我，你的svn跟网盘有什么区别。而且三个月后代码可能已经被很对人改过了，这时候你想把你的代码在commit上去，相信我，解决三个月来产生的冲突绝对让你产生想撞墙的冲动。

所以咯，为了我们的能够保持愉快的心情，我赞成第二种分支使用方式。大家都不可以在主干版本上直接commit，都必须在自己的branch上进行开发与调试，在自己的branch上积极commit，记录下log，可以在不影响他人的情况下随心所欲的记录下自己思想的轨迹，几年之后想要看自己当初看法的思路，看看当年的log,整个心路历程就都有了，想想是不是还有点小激动呢~(≧▽≦)/~

当你在自己的分支调试稳定之后，就可以向主干merge了。其实这里还有个问题不知你有没有想过，就是解决开发过程中别人上传的代码与你的开发产生的冲突还是需要解决，如果积累三个月，代码可能已面目全非，想要解决冲突可能仍然让你头疼到想撞墙。那怎么解决这个问题呢，答案是多跟trunk保持来往。

亲戚朋友时间长不走动就生疏了，branch和trunk时间长不来往互相就不认识了。所以我们开发过程中应该经常跟trunk保持联系。

怎么保持联系呢，不能总是向trunk合并，但是可以经常从trunk向自己的branch合并呀。每天开始一天的工作之前，我们都可以从trunk版本向branch进行合并，解决冲突，毕竟少量的冲突解决起来不会很难。

分支的使用方法

前面从宏观角度探讨了分支的使用方式，下面就要着眼于具体，说说如何操作了。这方面笔者目前也处于一瓶子不满半瓶子咣当的阶段，有什么错误大家及时纠正。

1. checkout出主干目录

第一步没什么可说的，大家非常熟悉了，在一个空目录下右键，点击checkout，在”URL of resposity”中输入主干版本的svn路径，点击OK即可。

2. 创建自己的分支

这里我们选在在svn服务器上创建我们自己的分支，在一个目录下右键，Tortoise->Branch/tag，如下图：

然后在to path中填入自己的分支的路径，填写log，选择HEAD revision in the respository，点击OK。

这样，我们就在svn服务器上创建了一个自己的分支。

3. 将自己的分支checkout出来

现在自己的分支还在服务器上，我们可以像检出主干版本一样在自己的工作路径下检出自己的分支。

4. 将自己的branch合并到trunk

合并分支这个事儿记住一点，向哪里合并，就在哪里操作。

既然是合并到trunk，就在trunk的路径下操作。在本机trunk目录下右键，Tortoise->Merge，如下图：

然后选择Reintegrate a branch，点击Next

然后填入自己的分支的URL，点击Next,可以先Test merge一下，最后点击Merge开始合并。

合并后记得在trunk路径下commit

5. 将trunk合并到自己的branch

还记得上文说过跟trunk保持来往吗，所以我们更多的操作应该是从trunk向自己的branch进行合并，解决冲突。

操作是在自己的branch目录下进行的，与向trunk合并的方式类似，右键，Tortoise->Merge，然后选择Merge a range of revisions，点击Next，输入trunk的路径，进行合并操作。

这里再次强调，经常性的从trunk向自己的branch合并，能够使自己的代码保持新鲜。另外不要吝啬于commit操作，反正也不会影响到别人，多多commit，多多记录log有百利而无一害。