git - git merge origin/master 和 git pull 的区别

Question

我正在本地分支“BDD-local”上工作，并希望从其他开发人员那里获得更改。 其他开发人员正在使用他们自己的分支，一旦他们对单元测试感到满意，他们就会将更改推送到远程仓库 (origin/master)。

我在这里浏览了几篇文章并获得了相互矛盾的信息。 很少有人谈论使用:

git fetch origin
git merge origin/master

有些人认为，'git pull' 应该得到更改。

我们的一位开发人员要求在没有“git fetch”的情况下使用“git merge origin/master”

有谁知道这些选项中哪个更好。我在我的本地分支上尝试了“git pull”，但它似乎没有用。但是如果我在本地 master 上执行 'git pull' 它工作正常(但是我希望它为本地分支工作)

Answer 1

获取、 merge 和 pull

git fetch 和 git merge origin/master 将获取并集成远程更改。让我解释一个常见的场景。 origin/master 位于 C。有人推送 D。你在 E 和 F 上工作。请注意，在运行 git fetch 之前，你不会在本地存储库中看到 D。

   origin/master
    v
A-B-C-E-F < master
     \
     (D) < master on remote

现在你运行 git fetch。现在您可以看到 D，origin/master 已更新以匹配它正在跟踪的远程存储库。

A-B-C-E-F < master
     \
      D < origin/master, master on remote

现在你运行 git merge，给你这个:

A-B-C-E-F
     \   \
      D---G < master
      ^
    origin/master, master on remote

现在您已经将 master (E, F) 上的更改与 origin/master (D) 上的新提交集成在一起。

git pull 只是上述步骤的快捷方式。

git merge without fetch

在没有 git fetch 的情况下运行 git merge origin/master 是没有意义的。如果没有 git fetch，您的本地存储库将不知道远程存储库上的任何潜在更改，origin/master 也不会移动。所以你处于这种状态，其中 D 仅在远程而不在本地:

   origin/master
    v
A-B-C-E-F < master
     \
     (D) < master on remote

由于您的本地存储库没有 D，git merge origin/master 将简单地产生:

已经是最新的。

因为嘿，就您的本地存储库而言，master 已经拥有 origin/master 中的所有内容。

什么最好？

以上都不是。 :)

git fetch
git rebase origin/master master

或快捷方式，git pull -r，但我个人更喜欢在 rebase 之前查看更改。
这将在 origin/master (D) 之上重播您对 master (E, F) 的更改，而无需进行令人讨厌的 merge 提交。它产生:

A-B-C-D-E'-F' < master
      ^
   origin/master, master on remote

请注意所有内容都在一行中，您已准备好推送，而且历史看起来不像友谊手镯。

一个警告——永远不要 rebase 任何已经推送的提交。请注意，E & F 在 rebase 后变成了 E' & F'。使用新的 SHA 和所有内容完全重写提交。如果你 rebase 已经公开的提交，开发人员将在他们 pull 时为他们重写他们的历史。那太糟糕了，每个人都会对你投以恶毒的眼光，对你避而远之。