svn使用规范

标签：

开发相关

1.        每天至少获取一次所有相关代码，以降低代码冲突的概率。

2.        本地自动生成的文件不要提交到svn去。svn有个ignore的功能可以屏蔽特定文件。

3.        多提交，每次提交的时候内容少一点。

4.        不要提交不能通过编译的代码。结合多提交的原则，这里其实要求你把工作细分成很小的单元。有个小技巧是函数里面可以先throw new NotImplementException，下次提交再写实现。（抛异常是为了防止以后忘了写实现）

5.        如果提交的时候发现有版本冲突，建议做法是把自己的修改在本地备份一下，然后revert自己的所有修改，然后重新获取，然后把自己的修改重做一遍。因为我们每次只提交少量改动，所以‘根据本地备份的代码重做修改’的工作量很小。这么做的好处是不需要进行复杂的冲突合并操作，不容易引入bug。

6.        每次commit之前，检查一下自己的修改，看是否符合预期，有没有提交错误的东西。因为每次提交的东西很少，所以每次自己提交了什么也很容易检查。

发布相关

现在流行主干开发，也就是主要的开发工作都在master分支进行。

用svn做代码版本的发布，一般有两种方式：

?  Release Branch

n  要发布的时候，从master开一个RB.1.1.3之类的分支。然后master继续开发新功能，RB.1.1.3就负责修bug直到版本发布完成。

n  这个方法适合于比较大型的发布：大项目、大团队、测试和发布周期长。

n  优点是master和RB之间松耦合。

n  缺点是master和RB之间经常需要同步代码和修改，这种同步不但繁琐而且容易引入bug。

?  Release Tag

n  要发布的时候，在master上打一个RB1.1.3.1的tag发第一个beta。然后master继续开发。当发现发布的代码有问题时，改代码然后打个RB1.1.3.2的tag发第二个beta。然后master继续开发。这样不管是第几次发布成功了，我们都有对应的tag。

n  这个方法适合于较小的发布：小项目、小团队、发布周期短。

n  优点是敏捷。不需要同步代码。

n  缺点是master的开发容易干扰发布。如果发布周期太长，或者master需要做很大的后续开发，那么就会hold不住。

推荐用Release Tag的方式。发布过程中开发master代码可以先不调用或者if (false)，那么就不会影响发布。

svn使用规范

标签：

原文地址：http://blog.csdn.net/wwwsq/article/details/48241369