项目版本管理模型

版本管理在软件开发过程中十分常见，如下是常见的一种最佳实践，适用于所有的版本管理系统(svn, git等)。

发布分支：

软件开发有一个典型的循环：编码，测试，发布，然后重复。过程中会遇到如下两个问题：

1. 当测试人员在测试假定稳定版本时，开发人员需要继续开发新功能，不能因为测试而停止开发，且新开发未测试的功能也不能影响到发布版本的稳定性。
2. 可以找到老的发布过的源代码，当线上出现bug或者有紧急的功能需要上线的时候，可以直接依赖发布过的代码进行修复，而不用等主版本的发布。

典型流程建议：

1. 开发提交1.0版本的改动到 trunk
2. 开发结束，团队认为软件可以准备发布，从 trunk 上拷贝出一个分支 branch_1.0
3. 开发团队继续开发2.0版本的功能，提交到 trunk。
4. 测试团队对需要发布的 branch_1.0 进行测试，如果有bug则直接修改在 branch_1.0 上，直到该分支测试通过则停止修改。
5. 从测试通过的 branch_1.0 上拷贝一个分支 tag_1.0 作为最新发布版本的源代码，并将 branch_1.0 的改动merge回trunk。
6. 如果线上有bug需要修改，或者有紧急的功能需要添加上线（指上线时间必须要在2.0之前的改动），则在 branch_1.0 上进行修改，测试通过之后拷贝出 tag_1.1 进行发布，并将改动merge回trunk。
7. 循环该流程进行版本迭代。

特性分支：

当有复杂的修改，并且不希望干扰到 trunk 的稳定性或发布计划时，就需要使用特性分支。推荐流程如下：

1. 从最新的release分支中拷贝出特性分支，如从 tag_1.0 拷贝出 branch_new_feature，新特性相关的改动都提交到 branch_new_feature 中。
2. 如果特性分支的开发周期比较长，则需要使该分支和 trunk 或最新的release版本保持同步，merge到 trunk 或者最新的tag到 branch_new_feature 中。
3. 完成特性分支的开发之后，merge 回 trunk（如果和主版本一起发布），或者从最新的tag中打一个分支出来 branch_1.1，将特性分支merge到该分支中（不和主版本一起发布，所以只和最新的release版本进行merge）。
4. merge之后的代码通过测试后就可以发布了。
5. 删除已经merge回release的特性分支，保持仓库的整洁。

参考

Common Branching Patterns