git - 为什么在“为git push配置的本地引用”部分中存在分支，而在“为git pull配置的本地分支”中却没有分支

Question

我目前正在学习git，通过以下书籍“progit第二edi”。
在“检查遥控器”一节中，作者举了以下例子。

我注意到“为git pull配置的本地分支”一节中没有“标记条”分支，但在“为git push配置的本地ref”一节中有。我在想为什么会这样。
注：我理解“git pull”和“git push”是如何工作的。“为git pull配置的本地分支”中没有“降价条”分支，这让我很困惑。

Answer 1

这似乎是一个综合的例子，所以这可能只是一个错误。然而，这也可能是特定配置的副作用，其中本地分支markdown-strip没有上游集。
记住，任何分支的上游都是由两部分组成的设置，您可以使用一个命令设置：

git branch --set-upstream-to=<upstream> <branch>

例如：

git branch --set-upstream-to=origin/master master

或者使用两个单独的git config命令笨拙地配置：

git config branch.master.remote origin
git config branch.master.merge refs/heads/master

每个分支名称（如master）可以有一个上游集，也可以没有上游集。（也就是说，不能设置两个或多个上游。您可以设置一个remote和两个或多个merges，并且git show对它们做一些特殊的操作；但是这不是一个正常的配置，并且git branch --set-upstream-to不能也不会这样做。）
要以正常方式移除上游，请使用git branch --unset-upstream。下面，我以一种不正常的方式来做，尽管对git remote show origin的影响是相同的。（我删除了编辑器中的两个设置之一，因为这样可以在编辑器中撤消删除操作，这比输入git branch命令更容易。当然，我现在花了更多的时间来解释这件事，而不仅仅是用正常的方式。：-））
任何本地分支的上游都可以是另一个本地分支，但更典型的是，它被git称为远程跟踪分支。1您通常不希望或不需要取消设置上游。有时确实需要设置上游，但如果使用普通方法，则在首次推送新分支之前，无法为新分支设置上游：

$ git checkout -b newbr
... the usual stuff here ...
$ git commit
$ git branch --set-upstream-to=origin/newbr

这抱怨和失败，因为origin/newbr还不存在，因为我们在本地创建了newbr但还没有将它推到origin，所以在我们的库中没有origin/newbr。一旦我们运行git push origin newbr，就会在原点上创建newbr。这反过来又创造了我们自己的origin/newbr来记住我们刚刚在origin上创建的newbr，然后呼！-现在我们终于可以将origin/newbr设置为newbr的上游。
我认为在本例中，pro-git的作者有一个存储库，他们在其中本地创建了一个分支，然后将其推送到名为origin的远程，但从未开始在分支上运行git branch --set-upstream-to。
一个例子
例如，我的git repo for git副本配置了本地分支master，其上游设置为origin/master。如果我运行git remote show origin得到（在通常的先前输出之后）：

  Remote branches:
    maint  tracked
    master tracked
    next   tracked
    pu     tracked
    todo   tracked
  Local branches configured for 'git pull':
    master    merges with remote master
    stash-exp merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

（stash-exp是我在很久以前为git stash安装错误修复程序的地方）。如果我从merge = refs/heads/master中删除行.git/config并再次运行git remote show origin，则会得到：

  Remote branches:
    maint  tracked
    master tracked
    next   tracked
    pu     tracked
    todo   tracked
  Local branch configured for 'git pull':
    stash-exp merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

请注意，这仍然声称master pushes to master。事实上，由于origin存储库是只读的，所以没有任何东西会推送到任何地方。
如果我运行git push origin master，这个声明就是git将要尝试的。在这种情况下，我的git会调用他们的git，发现我们都有一个名为master的分支。我的git会建议他们的git将refs/heads/master设置为指向与我的refs/heads/master相同的提交。他们会拒绝他们的存储库设置为拒绝这样的尝试，但我的git不知道。
当我删除branch.master.merge = refs/heads/master设置时，git不再说master merges with remote master。我一放回去，我的吉特又开始说了一遍。这并不意味着我的master总是与他们的master合并：这只是意味着如果我要运行git pull，并且他们的master有新的提交，那么作为git pull的第二步，我的git将运行git merge origin/master（或多或少）。git pull命令使用上游设置来确定要执行的操作。但我从不运行git pull，因为git pull是一个糟糕的工具。
（我总是先git fetch，然后通常检查东西，如果合适的话运行git rebase，或者使用我的git mff别名，这是git merge --fast-forward的缩写。注意git rebase和git merge也使用上游设置。git status也是，因此设置上游非常有用，即使您避免git pull）
1成员，一个所谓的远程跟踪分支，比如origin/master是（a）在您的存储库中（它根本不是远程的，而是本地的）；和（b）只是您的git记住上次您的git调用origin的git时在origin上看到的东西的方式。你不能用“on”master的方式让你自己的分支，这意味着（c）远程跟踪分支甚至不是分支！所以一个远程跟踪分支（1）不是远程的，（2）确实记得你的git在另一个git上看到了什么，（3）不是分支。三个字中只有一个，tracking，在它的名字里是半真半假的！：-）
连字符的形式，远程跟踪，使这更好，因为它是一个东西，跟踪分支上看到的远程。整件事有点道理，但这个名字一开始很容易让人误解。人们认为远程跟踪分支就像本地分支，其实不然，但这并不是最糟糕的问题：它们过去被称为远程分支，有些人仍然使用这个短语。无论如何，这些本地名称和这些远程跟踪名称都只是名称；分支本身是另一个实体。见What exactly do we mean by "branch"?
2What, never? Well, hardly ever!