敏捷开发下的版本管理

如何提高敏捷开发环境下开发和测试效率？

离不开好的版本管理方法。

第一步，设计好的版本管理模型

1. Master

顾名思义，既然名字叫Master，那么该分支就是主分支的意思。master分支永远是production-ready的状态，即稳定可产品化发布的状态。

2. Develop

开发分支，我们平常开发的一个主要分支了，不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。

3. Feature branches

功能分支。这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当我在一个大的develop的迭代之下，往往我们会把每一个迭代分成很多个功能点，并将功能点分派给不同人的人员去开发。每一个人员开发的功能点就会形成一个feature分支，当功能点开发测试完毕之后，再合并到develop分支。

4. release branches

预发分支。这个分支系列从develop分支出来，进行预发环境下的测试，如果出现缺陷，那么就在该release分支下进行修复，修复完毕测试通过后，即分别并入master分支后develop分支，随后master分支做正常发布。

5. Hotfix branches

紧急线上修复，当线上出现bug且特别紧急的时候，就可以从master拉出分支到这里进行修复，修复完成后分别并入master和develop分支。

第二步，管理策略

在使用SVN管理版本时，其中develop的主程序必须是从master的稳定版内容merge过来，为了避免代码在开发时开发人员相互干扰，因此将根据产品人员提交的产品路线的需求单位进行特性研发，因此将产生的分支命名为feathers branch,边开发边在本地调试修改，因此一个版本会有多条feathers branch，且不断提交新的覆盖原有。

当该分支代码通过了code review,项目组长即可以将此段代码合并入develop，所有特性都集成进入develop主线时，即可发布release Branch ，交给测试人员进行测试，

当测试通过所有的预发分支进行测试，开发在预发分支上进行bug的修复，完成后即可以提交入master

最后，master上的代码为最终合并入develop中。

在master上线过程中一旦发现紧急版本升级将进入hotfix branch，因为此时代码修改并非是全量修改，而是正对某bug的紧急修复，因此产生的版本为1.1.X，厉害者X可达3000以上的四位数。

循环往复，据说比版本管理已经在国外应用的非常成熟，且国外相当多的开源软件都是如此管理，如git。