如何解释" git pull --rebase"简单来说?

时间:2017-12-02 09:55:11

标签: git git-rebase git-pull

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

  1. 一般来说,git pull是关于合并 a" remote"分支到本地"分支。
  2. 更详细地说,git使用" remote"的内容。分支到"更新" /"修改" " local"的内容分支。
  3. 更详细地说,如果在" local"中修改了文件。分支但不在"远程"分支,然后在合并之后,文件的内容将与" local"中的内容相同。科。反之亦然。如果在"远程"上修改了文件分支但不在" local"分支,内容将取自" remote"分支。
  4. 如果在两个分支中修改了文件("本地"和#34;远程"),git将尝试从两个分支进行修改。如果更改发生在文件的不同位置,则两个更改都将应用并在合并后出现在文件的内容中。
  5. 如果更改发生在同一个地方,我们就会知道"合并冲突"为简单起见,我不打算触及这个案例。
  6. 作为合并的结果,我们修改了" local"因此我们需要提交"。
  7. 现在我想对git pull --rebase得到同样的解释。我不想使用" head"," index"," fetch"," upstream"因为这些术语/概念只会让像我这样的初学者感到困惑。我知道我需要学习这些"高级"概念和我通过阅读教程来实现,但就目前而言,作为学习过程的一部分,我想理解git pull --rebase

    ADDED

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

2 个答案:

答案 0 :(得分:7)

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

  • git fetch基本上通知本地回购它不知道的更改。

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

问题是如果两个回购没有同步就发生了事情,它们可能会分歧:

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

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

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

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

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

这就是区别。一个结果是,如果你不进行rebase,你的repo的历史包含一些状态(如果你愿意,你可以在以后回放),其中应用了“x”更改但是没有“o”更改。在重新定位后,存储库中没有这样的位置。

答案 1 :(得分:1)

简单:只要您的作品是本地作品(意味着它尚未推送),git pull --rebase将用于在更新的历史记录之上重播您的本地作品。

git fetch将使用远程仓库的最新提交更新所述历史记录(例如origin/master)。
然后,您的工作(您的master分支的本地提交)将在更新的历史记录之上逐一重播(这就是rebase的作用)。

这个想法是,当你想要推送时,说推送将非常简单,并且不需要合并,因为你的提交只是在origin/master之上完成的新提交。

请注意,您可以完全隐藏该rebase部分since Git 2.6

git config pull.rebase true
git config rebase.autoStash true

即使rebase不顺利而你必须中止,Git也会为你恢复当前隐藏的工作since Git 2.10