如何分支和tags,这个是经常被争议的话题,参考svn最佳实践,主要有以下三种方式:
The Never-Branch system
通常在项目的初期,还没有发布可运行的版本。
用户每天都把代码提交到/trunk
在复杂的任务可能会出现/trunk的代码处于通不过编译的错误状态
非常简单的策略,不需要merge代码,不需要学习分支和tag。
The Branch-When-Needed system
这个需要维护分支和trunk,merge,但相对轻量级的解决方案,如果经常有一些小的变更,极少有很大的变更,
这种方式可以避免大量的分支管理和merge操作。
用户把代码提交到/trunk上
/trunk每次变更都应该能通过编译和回归测试
一个很大的需求不要在/trunk上开发,因为可能影响别人。
当有很大的需求和实验性的功能需要开一个新的分支,并在开发完成时将必要的功能合并到trunk上。
这种方式trunk必须保持稳定,但是可以避免很多的merge操作。
The Always-Branch system
这个相对重量级一些:
每个人都工作在自己的分支上
当功能完成后,将所有的分支必要的功能merge到trunk上。
trunk必须保持一直非常的稳定,会导致很多的merge冲突。
The Never-Branch system
通常在项目的初期,还没有发布可运行的版本。
用户每天都把代码提交到/trunk
在复杂的任务可能会出现/trunk的代码处于通不过编译的错误状态
非常简单的策略,不需要merge代码,不需要学习分支和tag。
The Branch-When-Needed system
这个需要维护分支和trunk,merge,但相对轻量级的解决方案,如果经常有一些小的变更,极少有很大的变更,
这种方式可以避免大量的分支管理和merge操作。
用户把代码提交到/trunk上
/trunk每次变更都应该能通过编译和回归测试
一个很大的需求不要在/trunk上开发,因为可能影响别人。
当有很大的需求和实验性的功能需要开一个新的分支,并在开发完成时将必要的功能合并到trunk上。
这种方式trunk必须保持稳定,但是可以避免很多的merge操作。
The Always-Branch system
这个相对重量级一些:
每个人都工作在自己的分支上
当功能完成后,将所有的分支必要的功能merge到trunk上。
trunk必须保持一直非常的稳定,会导致很多的merge冲突。