-----邮件原件-----
主题: RE: 讨论
嗯,文章原话“共同基础版本”提法并不清晰,可能是这个原因让你Confuse了。
关于分支合并,一般来说,是把整个分支的改动都合并过来,这样,就对应你信中的第二幅图。
而有时侯,我们并不想把分支上的所有内容都合并过来。
比如分支是补丁版本分支,其上完成了两个Bug fix,
一个是work around(临时解决方案)的,不应该合并到主干;另一个是可以合并到主干的,
这时,我们合并操作希望之合并第二个任务,不合并第一个任务。
于是,就不是整个分支都合并过来了。只合并第二个任务对应的改动。
不论是图一的情况,还是图二的情况,都是合于矩形模型的,
区别是,根据具体情况的不同,选择了不同的版本作为矩形的左上角。
因此合并的结果会不同。
是否回答了你的问题?
多交流!
Subject: 讨论
你好
我学习了你写的合并的矩形模型的文章,有点疑问想和你讨论一下。
你的文章中写到“矩形模型是版本合并基本模型,它反映了版本合并的本质。在版本合并时,合并两个贡献者版本,并参考它们的共同基础版本,来得到一个结果版本。这样,一共是四个版本,就好像矩形的四个顶点。请注意到这里所说的共同基础版本并不一定是共同祖先版本。”
我的理解是,如果在分支开发时的合并则必须参考共同主干祖先版本,否则合并可能会导致丢失内容。
我举右图这个例子来说明
从右图2种情况可以看出采用不同的共同基础版本将导致合并结果的变化,合并结果A中丢失了代码行“d”,在日常并行开发中,代码是逐步完善的,合并结果B是我们期望的。
不知我的理解是否正确,想听听你的想法?