版本控制分支模型.docxVIP

版本控制 分支模型LiangGzone2013-11-10 为什么要用分支场景：假设我们是某个互联网公司的开发人员。我们正在进行一个长期的大项目开发，开发的结束日期可能是一个月以后，但是这个时候，由于正在运行的网站出现一些严重的bug需要紧急的修复；同时，市场部提出要在网站中加一段广告代码，以便进行网站推广，要我们尽快加入到系统中，这次推广要持续一周。分析：我们需要同时进行三件事情正在进行中的长期的项目开发工作重要，不紧急紧急的BUG修复重要，紧急广告代码（新需求）的添加不重要，紧急你的选择：A：继续进行手中的项目，等完成了这个项目在进行BUG修复以及新功能的添加。B：停下手中进行的项目，在现在的代码基础上完成bug修复和新功能的添加。B+：停下手中进行的项目，在生产环境的代码基础上完成bug修复和新功能的添加，完成后，将这次变更的代码复制在正在进行的项目中。C：停下手中进行的项目，将生产环节的代码做一个tag，并且在这个tag之上衍生出一个版本分支，在这个版本分支上完成bug修复和新功能的添加。完成修复以及添加之后，在这个分支之上再做一个tag，同时合并进入正在进行的项目。D：停下手中进行的项目，将生产环节的代码做一个tag，并且在这个tag之上衍生出一个版本分支，在这个版本分支上完成bug修复，完成修复后再做一个tag，并且在这个tag之上衍生出一个新的版本分支来添加公共代码，同时将修复后的tag版本合并进入正在进行的项目。总结：什么情况下可以考虑不需要分支需求很稳定，不需要处理紧急情况。你确认你写的代码不会有任何的问题。开发的周期可以很长，对项目时间没有要求。实际情况你拿到的需求经常变化。你不敢保证写的代码不会有任何的问题。开发周期一般都很短，deadline很恐怖，需求方恨不得今天提出需求，明天就完成。 什么是分支前言：以Git 版本控制的分支为例。主要分支当开发开始执行时，我们这时候必须将程序代码分成两部份，一个是 master，另一个就是 develop。master主要用来Release产品专用，没事就不要去动它，假如要继续开发新功能，或者是修正Bug issue就利用 develop 这分支来开发，等待开发完成，要Release下一版产品时就将develop merge到origin/master 分支，这样才对，避免有人把 origin/master 改烂，底下这张图就说明了一切。次要分支Feature跟Release都是从develop分支出来，最后都merge回develop branch，然后主分支 master再去merge develop，这样就完成了。Hotfixes用来修正产品最重大bug，所以origin/master直接分支出来，修正之后在merge回master跟develop。新功能分支Hotfix分支 常用的分支模式不稳定主干策略特点：此种分支策略使用主干作为新功能开发主线，分支用作发布。使用：此种分支管理策略被广泛的应用于开源项目。此外，此种分支管理策略比较适合诸如传统软件产品的开发模式，例如微软Windows开发，对于互联网开发不是很适合。已经在主干上集成的新功能，如果达不到里程碑的要求，稳定分支就不能创建，很有可能影响下一个发布的计划。案例：比如freebsd的发布就是一个典型的例子。freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个release分支。注意： bug修改必须在各个分支之间合并。 稳定主干策略特点：此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。注意：每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。此种分支策略的缺点之一是如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。另外由于对于每