git - git pull是否在当前分支上运行？

Question

git pull在分支上运行是否正确？

在存储库中，当在不同分支上运行git pull时，它会做不同的事情吗？

如果未在git pull之后指定任何参数，

是否仅从远程origin中的同名分支 pull 到当前分支？

是否对其他分支机构有作用？

谢谢。

Answer 1

首先，不要使用git pull 。永远不需要此命令，如果您是Git管理员，请避免使用它，这样会更好。但是，如果您坚持使用它，因为它很方便—而且很方便—请记住，它只先运行git fetch，然后根据各种情况，通常再运行git merge。

Is it correct that git pull operates on branches?

是的，但是最好将 git pull视为运行两个Git命令，因为 git pull就是这样做的。

In a repository, when running git pull on different branches, will it do different things?

您不清楚“在不同的分支机构”和“做不同的事情”是什么意思。您可能的意思是:

git checkout branch1; git pull; git checkout branch2; git pull

或者:

git checkout branch1; git pull origin branch2 branch3

和后者有很大的不同。 (对“何时使用此表单”的简短回答永远不会。长期回答是“尚未:首先了解 Octopus merge ，然后重新阅读文档。然后，一旦您是Git管理员，您将意识到您也许绝对不应该将 Octopus 直接与 git pull merge ，但至少现在您知道什么时候可以安全使用 git pull了。”)

前者-在 git pull上运行 branch1，然后在 git pull上运行 branch2-只是经历了下面列出的四个步骤两次，一次是在 branch1上，另一次是在 branch2上。

When not specifying any argument after git pull,

• does it only pull to the current branch from a same-name branch in the remote origin?
• does it do anything for any other branch?

让我们首先处理第二部分，因为这很容易:“不，只要您不谈论远程跟踪分支。”

接下来，我们需要注意一个假设:该 Remote 名为 origin。您可以拥有多个 Remote ，如果有的话，显然其中最多一个名为 origin。即使只有一个 Remote ，也可以随心所欲地调用它。因此，从远程开始使用 origin的想法有点不稳定。

(不过，通常它是 origin。大多数人只有一个 Remote ，它的名称为 origin，所以只有 Remote ，而不是“可供选择的七个不同 Remote 之一”。)

当您不带参数运行 git pull时，Git将执行以下操作:

标识当前分支的上游。例如，branch1的上游可能是origin/branch1。请注意，此上游有两个部分:

远程名称，例如origin。

在远程上找到的分支的名称，例如branch1。

为了创建一个远程跟踪分支，Git有效地将这两部分粘贴在一起，这就是为什么我们将其视为 origin/branch1的原因。但是仍然有两个部分。

不需要上游分支名称与本地分支名称匹配。这只是一个好主意。

(有时，当您有两个或多个远程对象时，您必须违反此“好主意”。例如，假设远程 fred有一个名为 develop的分支，而另一个远程 susan有一个名为 develop的分支。您现在同时拥有 fred/develop和您存储库中的 susan/develop。您想同时使用这两个名称；您将使用什么分支名称？也许您可以调用一个 fred-develop和另一个 susan-develop。但是现在上游名称不再与本地名称匹配: fred-develop的上游是 fred/develop，而不是 fred/fred-develop。)

将此上游分为两部分:远程和在远程上看到的分支名称。

使用几个参数运行git fetch。 git fetch步骤将使用 Remote 的URL调用另一个Git。一旦您的Git在网络电话上安装了外部Git，您的Git将获得他们在分支机构中拥有的任何新提交，而您尚未拥有任何新提交。

假设当前分支为branch1，上游分支为origin/branch1。如果您自己的Git不太古老(至少是1.8.4版)，则会更新origin/branch1。 (如果您的Git早于该版本，则git pull提供的参数会阻止您的远程跟踪分支被更新。这不是一个好情况，您应该更新您的Git版本。所有这些都起作用，很难解释。)如果您完全避免使用git pull，那么Git 1.8.3和更早版本执行此操作的怪异方式将不再重要，因为git fetch origin会更新您的所有远程跟踪分支，即使在这些较旧的Git版本中也是如此。)

现在git fetch在存储库中的那些新提交中，在origin/branch1远程跟踪分支下，您都已准备就绪。以后的git fetch将很快完成，因为您现在有了这些新的提交。

使用几个参数运行git merge或其他一些Git命令。

这是最后一步(通常是 git merge)会影响您的分支。当 git merge成功执行时，通常会进行新的提交。与所有普通的Git命令一样，进行新的提交会将提交添加到当前分支中。当 git merge进行快进而不是进行新提交时，这也会影响您当前的分支。

因此，我们可以这样说:当 git pull运行 git merge时， git merge步骤会影响您当前的分支，就像 git merge 总是会影响您的当前分支一样。

但是，您可以要求 git pull运行其他第二个命令。具体来说，您可以进行设置，以便 git pull运行 git rebase而不是 git merge。为了弄清楚它的作用，我们必须看一下 git rebase的作用，这更加复杂-但最终，它也会像 git merge .1一样影响您当前的分支。因此，我们也可以说:当 git pull运行 git rebase时， git rebase步骤以与 git rebase 总是 1相同的方式影响您的当前分支。

放在一起

当我们将所有这些事实放在一起时，最终会看到 git pull的第二个命令会影响当前分支。并且，它仅影响当前分支，因为 git merge和 git rebase仅在当前分支上起作用。

(第一个命令 git fetch步骤会影响远程跟踪分支。但是，由于这些只是Git记住外来Git所获取内容的方式，所以上一次它是从外来Git获取内容的，这并不是很重要。)

最后， 不要使用git pull 。使用 git fetch，然后使用根据 fetch附带的内容选择的任何命令: git merge或 git rebase。

1有一种方法可以使 git rebase影响另一个分支，但是-幸运的是， git pull不使用它。 (除非您知道自己在做什么，否则您可能也不应该这么做。这很简单:从字面上看，它只是先执行另一个分支名称的 git checkout，然后继续进行，就像您自己完成此操作一样，并且未指定额外的分店名称。)