从原点拉出时“git pull”命令之间的区别？答案

【问题标题】：Differences between "git pull" commands when pulling from origin?从原点拉出时“git pull”命令之间的区别？
【发布时间】：2013-03-25 16:47:21
【问题描述】：

这些命令有什么区别？：

# 1
git pull
# 2
git pull origin
# 3
git pull origin master
# 4
git pull origin/master
# 5
git pull origin HEAD:master

【问题讨论】：

好吧，即使在阅读了手册页之后，也不是在所有情况下都清楚到底发生了什么。例如：git pull 没有配置上游是什么意思？（手册页仅声明默认配置为上游。）
简而言之：1. 如果没有当前分支的配置，将会失败，否则会像 2. 使用远程名称一样。 2. 将使用给定远程的默认获取配置（并合并第一个），而在 3. 中，您指定要获取和合并的内容。 4.无效，恕我直言。 5.（如果有效），将远程 HEAD 放入 refs/remotes/origin/master 并合并。
投票重新提出这个问题，因为不幸的是，它是site:stackoverflow.com git Difference "git pull" "git pull origin master" 的搜索结果之一。

标签： git

【解决方案1】：

pull 基本上是一个fetch（它将一些提交和相关对象从远程存储库获取到您的存储库中），然后是一个将这些“应用”到您的工作副本的操作。第二阶段默认使用merge 完成，但您可以将pull.rebase 变量设置为true，然后它将改为变基。

pull 命令会弹出两个问题。首先是，究竟获取了什么？第二个是，它如何将这些更改应用于我的工作副本？让我们从第一个开始。命令的完整形式是

git pull [options] [repository] [<refspec>...]

options 是控制行为的标志（例如 --rebase 使 pull 工作为 fetch + rebase，即使 pull.rebase 是 false）。

repository 是要从中获取的远程的名称（或 URL）。

refspecs 是一种简洁的方式，用于指定要获取远程上的哪些引用以及要将它们放在当前工作副本中的哪个位置。

让我们首先采用最明确的形式。

 git pull origin branch1:branch2

这基本上是说，将引用branch1 中的更改拉到名为origin 的远程服务器上，然后将它们合并（或变基）到本地分支branch2。例如，如果我说git pull origin master:dev，我将获得一个名为dev 的本地分支，它将指向与master 相同的提交。如何指定 refspecs 的详细信息是here。您可以使用* 来指示多个参考规范。例如，git pull origin refs/heads/*:refs/heads/* 会将所有分支（存储在heads 下）拉到本地存储库中，并将它们合并到具有相同名称的本地分支中。

现在，让我们一个一个去掉参数来讨论默认值是如何工作的。首先，我们可以从 refspec 中删除目标，然后简单地说 git pull origin branch1。这将首先将fetch 远程分支branch1 放入您的本地存储库。它将作为名为@987654350@ 的临时参考提供。之后，它将运行git merge FETCH_HEAD，这会将这个分支合并到您当前的活动分支中（即HEAD）。这通常在您位于本地分支并希望从远程获取更改到该分支时完成。

现在，让我们完全放弃branch1，直接说git pull origin。现在，git 知道从哪里获取 (origin) 但不知道要获取什么。它对此有一些默认值。大多数情况是当您的配置文件有一个branch.<name>.merge 选项时（这是一个名为merge 的条目，位于[branch "master"] 之类的部分内）。如果是这样，它将使用那里的 refspecs 进行操作。

如果我们完全删除origin 并简单地说git pull，它将检查配置以查看是否有branch.<name>.remote 指定要从哪个遥控器提取。连同上面的内容告诉你要拉什么。

您的第 4 点和第 5 点不是正常用例。如果您有一个名为origin/master 的遥控器，那么第一个是有意义的，这不太可能。 origin/master通常是跟踪远程origin 上的master 分支的本地引用。第二个将尝试获取远程HEAD 上的更改（默认分支通常是master），然后将它们合并到本地master。虽然这可能是您想要定期执行的操作，但该命令非常不合常规，并且不是我经常看到的。

我跳过了一些细节，但这些应该足以让您在日常工作中保持安全和舒适。有关所有血腥细节，您可以查看git pull 的手册页。

【讨论】：

“例如，如果我说 git pull origin master:dev，我将获得一个名为 dev 的本地分支，它将指向与 master 相同的提交。”所以你会下载一个名为 dev 的新分支，它会指向 master？
不，你会从远程获取分支master，但它会在本地调用dev。
git pull origin refs/heads/*:refs/heads/* 对我不起作用，我得到了no matches found: refs/heads/*:refs/heads/*。我也试过git pull origin refs/remotes/origin/*:refs/heads/*，但也没有用。我不认为在一个命令中拉出所有远程分支是可能的，随后将所有这些分支合并/重新定位到它们随后的本地分支中也是不可能的。

【解决方案2】：

git pull 是一个方便的命令，它同时做不同的事情。基本上它只是git fetch 的组合，它连接到远程存储库并获取新的提交，git merge（或git rebase）将新的提交合并到您的本地分支中。由于涉及到两个不同的命令，git pull 的含义并不总是很明显。

您可以为本地分支配置上游。全新克隆后，您将拥有一个本地分支“master”、一个远程“origin”，并且您的 master 分支将“origin/master”作为上游。我假设下面的设置。（您可以使用 git branch -vv 或查看 .git/config 来查看您的上游配置。）

现在回答你的问题：

git pull= git fetch origin + git merge origin/master（或任何你的上游）
git pull origin = git pull（只要源是您的上游远程）
git pull origin master = git fetch origin master+git merge FETCH_HEAD
git pull origin/master ：除非您有一个名为“origin/master”的遥控器，否则无效
git pull origin HEAD:master ：尝试直接将您的本地主机重置为 HEAD 指向原点的任何内容。（不要这样做。）

【讨论】：

为什么执行git pull origin HEAD:master 是个坏主意？
右边应该是远程分支。请参阅手册页中的警告。如果您使用它，请确保您知道自己在做什么。
如果我在其他分支，git pull 会拉那个分支或主分支
@aWebDeveloper：为了完整性：git pull origin HEAD:master 本质上（直到脚本在 Git 2.6 中用 C 重写）将HEAD:master 部分传递给git fetch，所以这就是git fetch为那一步做；然后使用git fetch 步骤得到的提交哈希合并或变基。 Refspecs 是 source:dest，所以 HEAD 被提供给另一个 Git 进行翻译。所以这取决于另一个 Git — 但通常另一个 Git 的 HEAD 是它的 master 的名称。如果您不是靠自己的master，merge-or-rebase 将使用您的 fetch-updated master (dest)（除非fetch 失败）。
另一件要小心的事情：永远不要做git pull origin br1 br2。看起来和感觉应该是git checkout br1; git pull origin; git checkout br2; git pull origin——但事实并非如此！相反，它实际上是：git fetch origin && git merge origin/br1 origin/br2，它将 both 获取结果合并到您的 current 分支中，Git 称之为 octopus 合并。这从来不是任何人想要的。可能git pull 应该完全拒绝该命令（任何真正确实想要它的人都可以先运行 fetch，然后再合并）。