“git merge"和“git rebase"有什么区别?

假设最初有 3 个 commit，A,B,C:

Suppose originally there were 3 commits, A,B,C:

然后开发人员 Dan 创建了 commit D，开发人员 Ed 创建了 commit E:

Then developer Dan created commit D, and developer Ed created commit E:

显然，这个冲突应该以某种方式解决.为此，有两种方法:

Obviously, this conflict should be resolved somehow. For this, there are 2 ways:

合并:

提交 D 和 E 仍然在这里，但我们创建了合并提交 M 继承了 D 的变化code> 和 E.然而，这会产生菱形形状，很多人觉得很困惑.

Both commits D and E are still here, but we create merge commit M that inherits changes from both D and E. However, this creates diamond shape, which many people find very confusing.

重新定位:

我们创建commit R，它的实际文件内容与上面的merge commit M 相同.但是，我们摆脱了提交 E，就像它从未存在过一样(用点表示 - 消失线).由于这种删除，E 对开发人员 Ed 来说应该是本地的，并且不应该被推送到任何其他存储库.rebase 的优点是避免了 菱形 形状，并且历史保持良好的直线 - 大多数开发人员都喜欢！

We create commit R, which actual file content is identical to that of merge commit M above. But, we get rid of commit E, like it never existed (denoted by dots - vanishing line). Because of this obliteration, E should be local to developer Ed and should have never been pushed to any other repository. Advantage of rebase is that diamond shape is avoided, and history stays nice straight line - most developers love that!