我该如何信任Git合并? [英] How can I trust Git merge?

查看:95
本文介绍了我该如何信任Git合并?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我不确定我可以信任Git自动合并。这是一个场景。



在master中创建一个程序:

 将0移至I. 
A.
PERFORM X-PROC。
如果我等于25则转到A.

开发者1创建一个分支并且注意到有一个错误:无限循环。他修复了这个问题:

 将0移至I. 
A.
将1添加至I.
PERFORM X-PROC。
如果我等于25然后转到A.

同时开发人员2使分支并以自己的方式修复错误:

 移动0到I. 
A.
PERFORM X -proc。
加1到I.
如果我等于25则转到A.



两位开发人员都测试他们的代码并发现它是正确的。两者合并为主:

 移动0至I. 
A.
加1至I.
PERFORM X-PROC。
加1到I.
如果我等于25则转到A.

无限循环回来了。

在我看来,这个问题在任何分布式开发环境中都会经常发生。当我测试这个时,Git没有报告合并冲突。有时候这个问题可能会在很长一段时间内不被发现。回归测试应该可以找到它,但回归测试也会在Git中合并,所以我们也不能相信它们。



我能做些什么?我需要在每次合并后都要读取代码吗?

解决方案


代码阅读后每一次合并?


当然是。



Automerge算法是有用的,但它们不是魔术;如果它们不冲突,它们只包含对文件两边进行的更改。无法保证所产生的更改编译或甚至不是乱码。不能保证逻辑不是完整的列车失事。 (有人推测Heartbleed的bug是automerge巧妙地改变逻辑的结果,并没有被复审。)

任何版本控制工具都是如此,做一个automerge(假设你使用的是过去15年左右写的东西,几乎可以肯定)。虽然这不是为了鼓励automerge,它解决了对同一个文件的两个改变,并且通常做的很好;一般情况下合并也是如此。如果修改某个文件 A ,并修改某个文件 B ,则不能保证合并是合理的。最佳实践:在提交或推送它们之前,您应该始终检查您的合并,即使它们自动成功自动合并。


I am not certain I can trust Git to merge automatically. Here is a scenario.

Create a program in the master:

    MOVE 0 TO I.
A.
    PERFORM X-PROC.
    IF I IS EQUAL TO 25 THEN GO TO A.

Developer 1 makes a branch and notices that there is a bug: an infinite loop. He fixes it:

    MOVE 0 TO I.
A.
    ADD 1 TO I.
    PERFORM X-PROC.
    IF I IS EQUAL TO 25 THEN GO TO A.

Meanwhile Developer 2 makes a branch and fixes the bug in her own way:

    MOVE 0 TO I.
A.
    PERFORM X-PROC.
    ADD 1 TO I.
    IF I IS EQUAL TO 25 THEN GO TO A.

Both developers test their code and find it correct. Both merge to the master:

    MOVE 0 TO I.
A.
    ADD 1 TO I.
    PERFORM X-PROC.
    ADD 1 TO I.
    IF I IS EQUAL TO 25 THEN GO TO A.

The infinite loop is back.

It seems to me that this problem must happen often in any sort of distributed development environment. When I tested this, Git did not report a merge conflict. Sometimes this problem could go undetected for a long time. A regression test should find it, but regression tests are merged in Git too, so we can't trust them either.

What can I do about this? Do I need to do a code reading after every merge?

解决方案

Do I need to do a code reading after every merge?

Yes, of course.

Automerge algorithms are helpful, but they're not magic; they just include the changes that were made to both sides of a file if they don't conflict. There's no guarantee that the resultant change compiles or is even not gibberish. There's no guarantee that the logic isn't a complete trainwreck. (Some have speculated that the Heartbleed bug was the result of an automerge changing the logic subtly and was not caught in review.)

This is true of any version control tool that does an automerge (which, presuming you're using something that was written in the last 15 years or so, almost certainly does.) Though this is not to impeach automerge, which resolves two changes to the same file and generally does a fine job; this is also true of a merge in general. If you modify some file A and I modify some file B, there's no guarantee that the merge makes sense.

Best practice: you should always review your merges before you commit or push them, even when they automerge successfully.

这篇关于我该如何信任Git合并?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆