获取、合并和拉取
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 合并而不获取
在没有git fetch 的情况下运行git merge origin/master 毫无意义。如果没有git fetch,您的本地存储库将不知道远程存储库上的任何潜在更改,并且源/主控将不会移动。所以你处于这种状态,其中 D 只在远程而不是在本地:
origin/master
v
A-B-C-E-F < master
\
(D) < master on remote
由于您的本地存储库没有 D,git merge origin/master 将简单地产生:
Already up-to-date.
因为嘿,就您的本地存储库而言,master 已经拥有 origin/master 中的所有内容。
什么是最好的?
以上都不是。 :)
git fetch
git rebase origin/master master
或快捷方式,git pull -r,但我个人更喜欢在我变基之前查看更改。
这将在源/主 (D) 之上重放您在主 (E, F) 上的更改,而无需令人讨厌的合并提交。它产生:
A-B-C-D-E'-F' < master
^
origin/master, master on remote
请注意,一切都在一条线上,您已准备好推动,而且历史看起来不像友谊手镯。
一个警告 - 永远不要对已经推送的任何提交进行变基。请注意,E & F 在变基后变成了 E' & F'。提交被完全重写,带有新的 SHA 和所有内容。如果您对已经公开的提交进行变基,开发人员将在拉取时为他们重写历史记录。这太可怕了,每个人都会给你邪恶的眼光并避开你。