ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 用分支实现交迭

用分支实现交迭

原创 Linux操作系统 作者:broadviewbj 时间:2012-07-04 17:27:40 0 删除 编辑

用分支实现交迭

是不是发布补丁版本这个词听起来比交迭这个词更熟悉一些?发布补丁版本是交迭的一种。让我们从这里开始谈起。

补丁版本

绘图产品SuperPen 1.0版,经过六个月的开发,终于上市!在大笔捞钱的同时,公司正在组织开发2.0版,引入更炫的功能,卖出更好的价钱!研发团队全体,继续日夜奋战。在一派大好形势下也有些不和谐的声音,一些用户抱怨,1.0版里有这个Bug、那个Bug……虽然公司解释,这些都会在2.0版里修复,2.0版会以优惠的价格卖给老用户。但是,有的用户坚持认为,应该免费提供对1.0版中的Bug的修复,并且现在就要提供,等不到三个月后2.0版啦。“好吧,好吧,”公司管理层决定,“我们出个1.1版,只包括对1.0版中的Bug的修复,不包括任何新功能。把1.1版免费发放给购买了1.0版的老用户。他们可别想趁机占便宜,得到2.0版里的新功能。”

开会回来,研发经理犯了难。“2.0版的研发工作都开始了一个多月了。已经为实现新功能做了很多新的修改。难道这些都作废,退到1.0版从头来?”配置管理工程师却胸有成竹,“头儿,我们用那种叫分支的方法,就可以实现1.1版和2.0版同时开发,哪个也不耽误。”

没错,现在是分支大显身手的时候了。先考查一下现在的情形:主干上比较古老的部分,是目标为1.0版的研发;主干上某一点,是1.0版本发布了。随后,主干上开始了目标为2.0版的研发,现在正在向前演进。

为支持1.1版,我们从主干上1.0版本发布对应的那一点起,做一个分支,岔出来。这条分支的目标是1.1版,也可能将来1.2版也在这上面。我们把这条分支命名为1.x。在这条分支上,我们修复1.0版用户发现的各个Bug。一个又一个关于Bug修复的变更集被提交到这条分支上。分支在向前演进。在经历了若干次集成、测试之后,1.1版在这条分支上正式发布!

1.1版称做补丁版本Patch Release),是因为1.1版跟1.0版相比,没有什么大的变化,主要是一些修修补补。注意补丁还有另外一个含义,不完整的发布。比如说,安装某软件,在用100MB的安装包安装后,再安装一个2MB的汉化补丁,把该软件的菜单都改成方块儿字。这个意义上的补丁,不是这里讨论的主题。

 

复用另一条分支上的改动

1.1版所做的工作和为 2.0版所做的工作,其工作目的不同,其代码修改不同,因此用两条分支来体现。然而,为什么一定要用分支的方式来实现,而不是用完全独立的两个目录或两个版本库来实现呢?主要原因是,分支除了有隔离的功能外,还对共享有比较好的支持。使用分支,便于彼此同步和复用。

理想的情形是,在1.x分支上,从1.0版起到1.1版之间所有的代码改动,都应该拿到主干上,贡献给2.0版。对于这种情形,可以使用版本控制工具提供的简单命令,一股脑儿地把改动从1.x分支合并到主干上来。

以上说的是理想的情形,1.x分支上的全部改动都应该拿到主干上。在实际项目中,并不是这么理想的情况。比如有个Bug,在1.1版上的修复,只是临时性的修复,治标不治本,因为治本的代价太大,需要改动软件中的一些底层结构。而在2.0版中,软件的相关底层结构已经优化,因此,这个Bug2.0版中已经不存在了。

对此,比较保险的解决办法是,对1.x分支上的每一个变更集,均由开发人员做出判断,是否适合合并到主干。挑挑拣拣,合适的拿,不合适的不拿

这是以变更集为基础的挑选工作。而在有些团队里,使用的是以变更请求条目为基础的挑选工作。这里的变更请求主要是缺陷修复请求,可能还有少量增强请求。考查所有目标为1.x分支的变更请求,看看是否同样适用于主干。如果适合,就把相应的变更集从1.x分支复制到主干。

有选择地合并比较保险,但其管理成本也是显然的。在有些项目中,大家宁可容忍把没必要合并的改动合并过来,也不愿花费可观的精力去把需要合并的改动挑出来。于是就会使用把1.x分支上的所有改动都拿过来这样的合并方法,就好像工作在理想情况下。

上面讨论的都是从1.x分支到主干的合并。可能还存在相反方向的合并。比如,如果由于某种原因,一个缺陷先在主干上修复了。不久又决定要在1.x分支上使用同样的方式修复该缺陷。这时,就需要个案处理,把对应的变更集从主干复制到1.x分支上。注意这个方向上的合并不应该成为主流,两边都有的缺陷通常应该在1.x分支上先修复,因为1.x分支邻近发布,对缺陷修复的需求更紧急。

不论是以上哪种合并方法,执行合并操作时,一般来说,大部分改动可以自动合并到另一个分支上。当然,合并可能产生冲突,比如说某个文件在两个分支上都改动了同一行,且改为不同的内容。这就需要人来解决,懂得源代码语义的人来解决。如果合并是由集成工程师或配置管理工程师主导的,那么出现合并冲突时,一定要找相关开发人员来解决,不要自己改代码。

除了代码合并冲突,还可能在编译时或运行时出现问题。这些问题的本质原因都是,在一条分支上的代码修改,是以当时这条分支上的源代码为基础的修改,它不一定适合放在另一条分支的末端的源代码上。如果这样的问题经常冒出来,严重干扰了目标分支上的代码质量,那么就要考虑先对合并过来的改动进行一定的质量保证工作,再最终提交到目标分支。而如果这类问题不多,那么依靠在目标分支上的(狭义)集成中或集成后的质量保证工作来发现和解决问题就可以了。

什么时候问题不多,什么时候问题多?一般来说,新的分支刚创建的时候问题不多,因为两个分支上的内容差不多。随着时间的流逝,两个分支上的内容相差越来越多,这时候把一个变更集从一个分支复制到另一个分支,就会越困难,出现各种问题的可能性就越大。可能需要因此而调整合并的策略,引入更多的检查。

关于不同分支间合并,还要注意合并的频率。如果合并工作一直拖着,过了很久之后积攒下大量的合并一起做,那么合并就会变成一件头疼的事。一团乱麻,出了问题不好解决。这也是因为大家已经对很久以前的改动不熟悉了,需要更多的时间回忆起来。可以考虑制定流程,每当提交一个变更集到1.x分支后,就要考查是否应该把它合并到主干。当然,定期地合并也不错,只要两次合并的间隔不要太久。

我们这里谈论的分支,可以是广义上的分支的不同具体形式:可以是狭义的分支,也可以是分布式版本控制工具中的不同的版本库,或者其他的方法。只要这些方法能够方便地做到不同(广义)分支之间的隔离和共享就可以。

 

本文节选自《未雨绸缪——理解软件配置管理(第2版)》

董越著

图书详细信息:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-733806

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13164110/viewspace-734580/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-02-22

  • 博文量
    1030
  • 访问量
    1611517