如何用简单的术语解释"git pull --rebase"？

Question

我想我理解git pull,这就是我如何解释它,我称之为"简单术语":

1. 一般来说,git pull是将 "远程"分支合并为"本地"分支.
2. 更详细地,git使用"远程"分支的内容来"更新"/"修改""本地"分支的内容.
3. 更详细地说,如果文件已在"本地"分支中修改但未在"远程"分支中修改,则在合并之后,文件的内容将与"本地"分支中的内容相同.反之亦然.如果在"远程"分支上修改了文件但未在"本地"分支中修改,则将从"远程"分支获取内容.
4. 如果在两个分支("本地"和"远程")中修改了文件,那么git将尝试从两个分支进行修改.如果更改发生在文件的不同位置,则两个更改都将应用并在合并后出现在文件的内容中.
5. 如果更改发生在同一个地方,我们就会知道"合并冲突",为简单起见,我不会触及这种情况.
6. 作为合并的结果,我们修改了"本地"存储库,因此我们需要"提交".

现在我想得到同样的解释git pull --rebase.我不想使用诸如"head","index","fetch","upstream"这样的术语,因为这些术语/概念只会让像我这样的初学者感到困惑.我知道我需要学习这些"高级"概念,我是通过阅读教程来实现的,但就目前而言,作为学习过程的一部分,我想要理解git pull --rebase.

添加

我想在某些时候我听到了以下解释.通过git pull --rebase.当我们合并时,我们不是以"对称"的方式进行,如上所述.相反,我们首先"忘记""本地"存储库中的更改,并仅应用"远程"存储库中的更改.通过这样做,我们基本上"复制"远程存储库.之后,我们将"本地"存储库中的更改应用于顶部.但是,我仍然不清楚它究竟意味着什么.特别是,"顶部"意味着什么.

Answer 1

我看到有两件事可以澄清:你关注的是两个分支中文件的状态,但更好的方法是考虑发生的变化集.第二个问题是git pull两个操作的简写:git fetch和git merge.是的,你写道"你不想使用像fetch"这样的词,但这不是一个"高级概念".如果你想了解发生了什么,你需要从那里开始.

• git fetch基本上通知本地回购它不知道的变化.

• git merge 将新到达的更改与您的本地更改统一起来.

问题在于,如果在没有同步的情况下两个回购都发生了事情,它们可能会分歧:

... b--o--o--o--o  (remote)
     \
      x--x--x      (local)

以上显示了从左到右的时间; 最右边的点是最近的.因此,新到的更改是对文件的旧状态的修改,标记为"b".

• git pull,即plain git merge,将尽可能最好地合并两个分支的最新状态.

• git pull --rebase将假装您的更改不是标记为"b"的状态,而是最新的远程状态.换句话说,它将尝试重写历史记录,使其看起来像这样:

  ... b--o--o--o--o              (remote)
                   \
                    x--x--x      (local)
  

这就是区别.一个结果是,如果你不进行rebase,你的repo的历史包含一些状态(如果你愿意,你可以在将来回放),其中应用了"x"更改但是没有"o"更改.在变基础之后,存储库中没有这样的位置.