fetch, 合并和拉取
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
现在,您已将主分支上的更改(E,F)与 origin/master 上的新提交(D)集成。
git pull
只是以上步骤的一种快捷方式。
没有进行 fetch 的 git 合并
执行 git merge origin/master
而不进行 git fetch
是毫无意义的。如果没有 git fetch
,您的本地仓库将不知道远程仓库中的任何潜在更改,而 origin/master 将不会移动。因此,您处于这种状态,即 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
,但是我个人更喜欢在rebase之前看到变化。
这将在origin/master(D)的基础上重放您在主分支(E、F)上所做的修改,而不需要一个丑陋的合并提交。它产生的结果为:
A-B-C-D-E'-F' < master
^
origin/master, master on remote
注意一切都在同一行,你准备好提交了,而且历史记录看起来并不像友情手链。
一个警告 - 永远不要对已经提交的提交进行变基。请注意,E&amp;F在变基后变成了E'&amp;F'。提交完全被重写,具有新的SHA和所有内容。如果您变基已经公开的提交,则开发人员在拉取时将其历史记录重新编写。那就很糟糕了,每个人都会用恶意的眼光看着你并回避你。
git pull
提供了哪些确切的参数? - dcastro