svn 主干and分支

本篇总结包括：

文章一主旨：如何理解主干和分支；文章二主旨：如何在myeclipse中创建分支，及切换，合并

自己理解：

开发项目稳定发布后，不再直接在主干上进行bug修改或功能添加，会拉分支出来，一切操作在分支上完成，然后将分支合并到主干，再发布就是新一个版本，这个分支就没了，下次要修改再拉一个分支，合并后，又是一个新版本。。。只是自己的理解，可能有误~~欢迎大家指正

文章一：

一：主干发布

先说主干发布模式: 以SVN库为例,大致将库分为trunk,branch,tag三种,主线发布就是公司要发布某个产品的V1版本,之前大家都做会在SVN的trunk上做开发,等trunk稳定了.开出一个分支B1,在B1分支上做V1版本的其它功能添加,bug修改等,并使用持续集成来验证B1的稳定性.直到V1版本达到要求,可以对外发布,并且发布成功后,进行从branch到trunk的merge操作,此时trunk上的内容变成了V1版本的内容,而后trunk上的内容不再允许修改.然后,再发布V2,这个时候,比如下一个版本要发布V2版,这时从trunk的V1版发布的那个点,开一个分支B2出来,再进行V2版的开发,并做持续集成验证V2版的稳定性.直到V2版也达到要求,并且对外发布以后,将B2merge到trunk上,此时的trunk上的内容又变成了V2版本的内容. 依次类推, 直到V3,V4,V5等.我们称这种发布模式为主干发布,因为主干上的东西永远都是发布后的产品,而且不允许修改.

如果按照这种方式发布的优点：

第一：可以随时保证trunk上的东西的稳定性，使trunk随时可用；

第二：大部分开发人员不会去触碰trunk，用分支的方式解决实际开发过程中的一些变更（需求变更或设计变更等）；

第三：可以从trunk上随时拿到已发布的任意一个版本。

如果按照这种方式发布存在的不足:

第一：开发的时候, 持续集成一直在验证着Branch上的稳定性和正确性,而对于release完成后merge到trunk上后,没有对trunk进行集成验证, 难以保证trunk的稳定性；

第二：违背了SVN的规范，把trunk库当成了tag库去使用；

第三：某些开源项目会采用这种开发（发布）模式，但其中对于验证要求非常严格，merge起来很费时，鉴于开源项目的特殊性，暂不做讨论；

第四：一般采用这种模式发布，是有自己的考虑在里面的。那就是trunk上的东西是不能损坏的，必须随时是好的，即使偶尔出现问题也能及时修正，但trunk已经完全失去了它做为主干的意义，也很难保证SVN库的一致性。

二：分支发布

再说分支发布模式：以SVN库为例,大致将库分为trunk, branch,tag三种,所有开发人员基于trunk进行开发,比如也是要发布V1版本的产品,到trunk上的内容稳定后,版本达到了要release的要求,这时从trunk上开分支出来,我们可以称这个B1分支上的内容为pre-release版,此时这个B1分支只为fixbug,除非有必须要加的新功能.这个时候呢,大部分的开发人员就可以在trunk上开发下一次的发布, 而只需要少部分开发人员基于B1分支fixbug.如果有bug需要在B1和trunk里面都fix的话,就会有少量的merge操作,如非必要,就省心了.B1分支开出来后,一旦release了,可以根据发布计划,选择是否需要保留.如果近期有发B1的update计划,则可以保留;如果近期都不会再有基于B1的开发,可以将V1发布这一时刻点的B1状态通过tag的方式记录下来,然后消亡B1分支.我们称这种模式为分支发布,因为分支才是发布的线,主干可以一直进行开发,而没有必要停止.

如果按照这种方式发布的优点：

第一：trunk做为开发主线，开发人员可以随时将自己符合要求的代码提交到trunk上，如果在没有必要的条件下，不开分支。同时对trunk做持续集成验证，最大程度上保证trunk的稳定性。

第二：对每次成功的持续集成都同时对库和集成环境做tag操作，发挥tag库的强大作用。

第三：最大量的减少了merge操作，降低了误差。一旦要发布产品，只需从一个稳定的版本（公司上层同意的）发一个分支出来，然后再投入少量的开发人员去进一步优化，主要是fixbug。而这时，大部分开发人员就可以投入到下一个版本的开发中,最大力度的使用人力资源。

第四：其它.

如果按照这种方式发布存在的不足:

第一：配置管理需要随时了解pre-release的分支是否需要保留，以为下一次发布update等做准备。

第二：如果有大型的变更，trunk可能会被破坏，但是如果有一套规范，可以把风险降到最低。（或者也可以通过开分支的方式来解决这种问题）

第三：如果想要真正发挥这种发布模式的威力，配置管理，变更管理，持续集成，质量管理，发布管理每一个模块都是不可少的。

文章2：

Eclipse下svn的创建分支/合并/切换使用

 最近接项目要求，要在svn主干上创建分支，用分支来进行程序的bug修改，而主干上进行新功能的开发。分支上的bug修改完，发布后，可以合并到主干上。项目程序可以在主干和分支之间进行切换，来实现主干和分支的同时维护。

       1.创建分支

        创建分支实际上就是将程序copy一份到指定的分支目录，如下图示：

在项目名称上点击右键，弹出菜单，选择“Team”，再选择“Branch/Tag”，弹出下面的页面： 

 

上图中的“Copy to URL”填写创建新分支的路径地址，后面会将程序copy到该目录下，形成新的分支。点击“Next”:

 

 

选择当前最新的版本，点击“Next”

 

如果勾选了上图下面的switch working copy to new branch/tag，eclipse的程序项目会自动切换到分支下。这里我们不选择，待会自己切换。

这样就创建了一个1.0的分支

         2.合并

         可以从主干合并到分支，也可以从分支合并到主干，根据需要可以选择合适的选项，如下图：

 

上图中的选项：

        1) 从主干合并到分支

        2) 从分支合并到主干

        3) 将主干上的修改合并到分支

        4) 合并2个分支到主干

        5) 从主干到分支，手工指定不需要合并的修改

        6) 从主干到分支，手工指定要合并的修改

 

上图显示没有任何修改，所以不用进行合并。

 

3.切换

在项目名称上点击右键，选择“Team” –> “switch to another Branch/Tag/Revision”。

 

选择需要切换的目的地址，点击ok即可。

 

这样，在项目里就可以在主干和若干分支间进行任意切换，来实现对不同版本/分支的程序进行修改提交操作。

文章转载地址：

http://blog.csdn.net/lisq037/article/details/17501327

http://blog.csdn.net/sky101010ws/article/details/52649568