首先，看一下教程最后给出的建议：

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

想象两个实际的场景：

• 一种是最简单的，根据官方的 tutorials 的，把另一个分支 rebase 到主分支中。

  

  这里，git rebase 会让 experiment 的指针直接来到 master 分支应用过原来的 experiment 的新的 commits 之后的最新的 commit 那里，如果 experiment 再有新的提交，会从这里重新去分叉，而原来的 rebase 之前的那个分叉就没了，当然，当前指针还是在 experiment 分支上，并没有切换到 master 主分支。我们如果继续，切换到 master 分支的话，那么，再去 merge experiment 分支的话，就将是快进合并，不会产生新的 commit，正是这个不会产生新的合并分支相关的 commit，就是我们所说的保持分支的整洁，

  $ git checkout master
  $ git merge experiment
  

  这样一来，我们 rebase 远端的中心主仓库的操作就也容易理解了。

• 第二种，考虑这样一种场景，远程有一个大家都在使用的主仓库，然后，

  • 我 fork 了一份到自己的仓库，然后，
  • 我把我自己 fork 的这份代码 clone 到本地进行开发，然后，
  • 我提交了两个新的 commit，然后，
  • 我发现，主仓库被更新了两个新的 commit，然后，
  • 我想更新一下主仓库的新的 commit，然后再推送到我自己远端的那个 fork 的仓库，然后，
  • 向主仓库提交一个 PR

按：如果遇到了冲突，那么，在我们解决完冲突之后，执行一下 continue 即可，

$ git rebase --continue

再按：我们其实可以不用看上面提到的一个复杂的例子，那个是违反原则的，反而不利于我们理解 git rebase。

再按：rebase 是相当于将当前分支的那些 commit 重放到新的分支的最新的 commit 之后，注意，是逐个重放，如果每个都有冲突，那么，每次都要停一下让程序员去手动解决一下，然后再 git rebase —continue.