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

Question

我想我明白了git pull这就是我解释它的方式，我称之为“简单术语”:

1. 一般来说，git pull是关于将“远程”分支 merge 到“本地”分支。
2. 更详细地说，git 使用“远程”分支的内容来“更新”/“修改”“本地”分支的内容。
3. 更详细地说，如果一个文件在“本地”分支中被修改，但在“远程”分支中没有被修改，那么 merge 后，该文件的内容将与“本地”中的内容相同“分支。反之亦然。如果文件在“远程”分支上被修改但在“本地”分支上没有修改，则内容将从“远程”分支中获取。
4. 如果文件在两个分支(“本地”和“远程”)中都被修改，那么 git 将尝试从两个分支中获取修改。如果更改发生在文件的不同位置， merge 后这两个更改都将应用并出现在文件的内容中。
5. 如果更改发生在同一个地方，我们就会遇到所谓的“merge 冲突”，为了简单起见，我不打算讨论这种情况。
6. 由于 merge ，我们修改了“本地”存储库，因此我们需要“提交”。

现在我想对 git pull --rebase 得到同样的解释.我不想使用诸如“head”、“index”、“fetch”、“upstream”之类的术语，因为这些术语/概念只会让像我这样的初学者感到困惑。我知道我需要学习这些“高级”概念，我通过阅读教程来学习，但现在，作为我学习过程的一部分，我想了解 git pull --rebase .

已添加

我想我在某个时候听到了以下解释。通过 git pull --rebase .当我们 merge 时，我们不是以“对称”方式进行 merge ，如上所述。相反，我们首先“忘记”“本地”存储库中的更改，只应用“远程”存储库中的更改。通过这样做，我们基本上按原样“复制”了远程存储库。之后，我们应用来自“本地”存储库的更改在顶部。但是，我仍然不清楚这到底是什么意思。特别是，“在上面”是什么意思。

Answer 1

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

• git fetch 本质上是通知本地仓库它不知道的更改。

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

要注意的是，如果事情在两个 repos 上都发生了没有同步的情况，那么它们可能会发生分歧:

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

上面从左到右显示时间；最右边的点是最近的。因此，新到达的更改是对文件的旧状态的修改，即标记为“b”的文件。

• git pull，即普通 git merge，将尽可能 merge 两个分支的最新状态。

  <

• git pull --rebase 会假装您所做的更改不是针对标记为“b”的状态，而是针对最新的远程状态。换句话说，它将尝试重写历史，使其看起来像这样:

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

这就是区别。一个结果是，如果您不进行 rebase ，您的 repo 历史记录将包含一些状态(如果您愿意，您可以在将来倒退到这些状态)，其中应用了“x”更改但不存在“o”更改。 rebase 后，存储库中没有这个地方。