合并源代码分支的避错方法
时间:2010-11-24 来源:slimzhao
最近又做了一次不同源代码分支的合并,想到了一些避免合并时出错的办法,主要用于比较大的源代码文件,自动合并后又产生大量冲突的情况。
1. 结对合并。但结对工作的质量提高取决于参与者挑刺的积极程度,如果一个人操作合并/比较工具,另一个人盯着屏幕看,如果两个人的注意力没有重合的部分,就可能取得比较好的效果,而如果两个人注意力的并集之外, 还有遗漏的地方,就有可能在这些遗漏的地方出现问题。 这个办法,我只是想到,没有实验。
2. 两个人分别合并,不check in, 在合并完成后,对合并结果进行比较,我直觉这个方法要好于第一个办法,因为在第一个办法中,结对的两个人还是有主从之分的,实际上同一个时间只有一个操作者。这样另一个人负起的责任其实完全由他自己确定,如果最终还出现漏洞,则责任不分明。而两个人分别合并,表面上看,是劳动力浪费了,实际上,这两个人都要对合并的结果负起完全责任,最重要的是,对于代码合并,正确的结果应该是几乎完全一样的,如果出现了不一致,则这两个人要同时review合并结果不一致的地方,集中注意力检查。之所以宁可浪费一个人的劳动力,是因为分支合并时引入的bug, 如果不在合并时解决,留在以后报出bug时再去检查,代价会更大,而合并分支这样的事,其实并不需要持续太长时间,一定程度上有机械性和重复性。这个办法我也没有实验,但从道理上想,应该是很有价值的做法。
3. 同一个人扮演两个人的角色,这样工作任务的分配上,合并仍属于同一个人,也就是我自己,这次我是拿自己做实验。在前一天,我第一次用VS的TFS 工具进行合并,在配置比较/合并工具Araxis时,出了岔子,导致本来以为很直观的保存文件操作,其实没有真正保存文件,工具也没有错误提示,所以耽误了一些工作,但我并没有放弃这次合并,而是把它做完,之后,不check in, 把合并后的代码压缩封存。 到第二天。注意一定要隔天,不要在同一天之内重复做同样的事,否则大脑的习惯性注意力还是一样,导致你只会注意到已经注意过的部分,而不能形成不同的注意力范围。今天我把所有的合并结果全清0,重头再合并一次。 然后,对这次合并的结果和上一次合并的结果进行递归比较。 这是我最近实验的一次。
接下来要注意一下,有没有bug是因为合并时的遗漏引起的,我个人觉得上面的方法2和方法3可以有效地防止因合并而引入的bug.
1. 结对合并。但结对工作的质量提高取决于参与者挑刺的积极程度,如果一个人操作合并/比较工具,另一个人盯着屏幕看,如果两个人的注意力没有重合的部分,就可能取得比较好的效果,而如果两个人注意力的并集之外, 还有遗漏的地方,就有可能在这些遗漏的地方出现问题。 这个办法,我只是想到,没有实验。
2. 两个人分别合并,不check in, 在合并完成后,对合并结果进行比较,我直觉这个方法要好于第一个办法,因为在第一个办法中,结对的两个人还是有主从之分的,实际上同一个时间只有一个操作者。这样另一个人负起的责任其实完全由他自己确定,如果最终还出现漏洞,则责任不分明。而两个人分别合并,表面上看,是劳动力浪费了,实际上,这两个人都要对合并的结果负起完全责任,最重要的是,对于代码合并,正确的结果应该是几乎完全一样的,如果出现了不一致,则这两个人要同时review合并结果不一致的地方,集中注意力检查。之所以宁可浪费一个人的劳动力,是因为分支合并时引入的bug, 如果不在合并时解决,留在以后报出bug时再去检查,代价会更大,而合并分支这样的事,其实并不需要持续太长时间,一定程度上有机械性和重复性。这个办法我也没有实验,但从道理上想,应该是很有价值的做法。
3. 同一个人扮演两个人的角色,这样工作任务的分配上,合并仍属于同一个人,也就是我自己,这次我是拿自己做实验。在前一天,我第一次用VS的TFS 工具进行合并,在配置比较/合并工具Araxis时,出了岔子,导致本来以为很直观的保存文件操作,其实没有真正保存文件,工具也没有错误提示,所以耽误了一些工作,但我并没有放弃这次合并,而是把它做完,之后,不check in, 把合并后的代码压缩封存。 到第二天。注意一定要隔天,不要在同一天之内重复做同样的事,否则大脑的习惯性注意力还是一样,导致你只会注意到已经注意过的部分,而不能形成不同的注意力范围。今天我把所有的合并结果全清0,重头再合并一次。 然后,对这次合并的结果和上一次合并的结果进行递归比较。 这是我最近实验的一次。
接下来要注意一下,有没有bug是因为合并时的遗漏引起的,我个人觉得上面的方法2和方法3可以有效地防止因合并而引入的bug.
相关阅读 更多 +