每次我尝试一个rebase，我都会卷入一个无限循环的无法解决的冲突中。在解决x冲突之前，y冲突出现，然后x冲突再次出现，以此类推。
关键是（显然）merge，甚至cherry-pick，提供了与rebase相同的功能，不是吗？如果不是，那么rebase的作用是什么？
最佳答案
rebase重写历史。它不仅仅是一个需要实践的非常先进的工具（而且可能是危险的，因为它重写了历史……小心使用merge）。当cherry-pick的用法与git push -f类似时，这个过程是完全不同的。rebase：
从源下载更改
合并本地分支顶部的更改
解决冲突并提交merge：
从源下载更改
将本地分支重置为历史中的公共点（本地/远程回购共享的提交）
快速前进到原点
在新提交的基础上逐个应用提交
解决冲突并提交每个本地更改
在这种情况下git fetch origin && git merge origin/master的最大优点是，你只需更新本地回购协议并在上面应用提交，不会有任何“严重”的合并提交说“嘿，我刚把这些东西合并进来了”。缺点是，如果你有大量的提交修改了相同的文件，由于没有“gross”合并提交，您将不得不一次又一次地解决冲突。
但是，再次强调，git fetch origin && git rebase origin/master是一个真正的高级工具，用于重写历史。您可以修改以前的提交标题、删除以前的提交、将多个提交压缩在一起等。Read up on it!