为了便于理解可以看到我的身影。

Rebase将改变提交哈希，因此如果你想避免大量冲突，只需在分支完成/完成时使用Rebase作为稳定。

假设你已经在你的特性分支中提交了3次，当你想要将你的特性分支更改发送到主分支时。 你有两个选择

git merge:在这种情况下，主分支将只接收1次提交(合并3次提交) git rebase:在这种情况下，main branch将接收3次提交

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

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

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

走：

提交D和E仍然在这里，但是我们创建了合并提交M，它继承了D和E的更改。然而，这创建了菱形，许多人对此感到非常困惑。

变基:

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

为了便于理解可以看到我的身影。

Rebase将改变提交哈希，因此如果你想避免大量冲突，只需在分支完成/完成时使用Rebase作为稳定。

我发现了一篇关于git rebase vs merge的非常有趣的文章，想在这里分享一下

如果你想看到完全相同的历史，你 应该使用归并。Merge保存历史，而rebase重写历史。 合并会向历史记录中添加一个新的提交 重基可以更好地简化复杂的历史记录，你可以通过交互的重基来改变提交历史。

Git rebase更接近于merge。rebase的区别是:

本地提交被临时地从分支中移除。 运行git pull 再次插入所有本地提交。

这意味着所有本地提交都被移动到最后，在所有远程提交之后。如果您遇到合并冲突，也必须解决它。