合并的矩形模型

-----邮件原件-----
主题: RE: 讨论

嗯，文章原话“共同基础版本”提法并不清晰，可能是这个原因让你Confuse了。

关于分支合并，一般来说，是把整个分支的改动都合并过来，这样，就对应你信中的第二幅图。

而有时侯，我们并不想把分支上的所有内容都合并过来。

比如分支是补丁版本分支，其上完成了两个Bug fix，

一个是work around（临时解决方案）的，不应该合并到主干；另一个是可以合并到主干的，

这时，我们合并操作希望之合并第二个任务，不合并第一个任务。

于是，就不是整个分支都合并过来了。只合并第二个任务对应的改动。

不论是图一的情况，还是图二的情况，都是合于矩形模型的，

区别是，根据具体情况的不同，选择了不同的版本作为矩形的左上角。

因此合并的结果会不同。

是否回答了你的问题？

多交流！

Subject: 讨论

你好

我学习了你写的合并的矩形模型的文章，有点疑问想和你讨论一下。

你的文章中写到“矩形模型是版本合并基本模型，它反映了版本合并的本质。在版本合并时，合并两个贡献者版本，并参考它们的共同基础版本，来得到一个结果版本。这样，一共是四个版本，就好像矩形的四个顶点。请注意到这里所说的共同基础版本并不一定是共同祖先版本。”

我的理解是，如果在分支开发时的合并则必须参考共同主干祖先版本，否则合并可能会导致丢失内容。

我举右图这个例子来说明

从右图2种情况可以看出采用不同的共同基础版本将导致合并结果的变化，合并结果A中丢失了代码行“d”，在日常并行开发中，代码是逐步完善的，合并结果B是我们期望的。

不知我的理解是否正确，想听听你的想法？