git - origin/HEAD 是如何设置的？

Question

我设置了一个分支来跟踪原始引用。 git checkout <branchname>切换到那个分支，并且一个 git status会告诉我我的分支离原点有多远，但令我惊讶的是 origin/HEAD仍然指向 origin/master ，而不是 origin/<branchname>

所以我的问题是，在什么情况下 origin/HEAD 会移动？

编辑:

我很欣赏有关如何移动 origin/HEAD 的答案，但我对“有机地”移动它的原因很感兴趣，除了我明确告诉它这样做之外。

例如，当我切换分支时，git 将 HEAD 指向我正在 check out 的分支，所以我很惊讶 origin/HEAD 没有以相同的方式移动。

Answer 1

首先请注意，您的问题显示出一些误解。 origin/HEAD 表示远程上的默认分支，即您调用 origin 的远程存储库中的 HEAD。当您在 repo 协议(protocol)中切换分支时，您不会影响它。远程分支也是如此；你的 repo 中可能有 master 和 origin/master，其中 origin/master 代表 master 的本地副本> 远程存储库中的分支。

origin 的 HEAD 只有在您或其他人在远程存储库中实际更改它时才会更改，这基本上永远不会发生 - 您希望默认分支和公共(public)存储库在稳定分支上保持不变(可能是大师)。 origin/HEAD 是一个本地引用，表示远程存储库中 HEAD 的本地副本。(其全称是 refs/remotes/origin/HEAD。)

我认为上面的内容回答了您真正想知道的内容，但是继续回答您明确提出的问题... origin/HEAD 在您克隆存储库时自动设置，仅此而已。奇怪的是，它不是由 git remote update 之类的命令设置 - 我相信它会改变的唯一方法是手动更改它。 (我所说的更改是指指向不同的分支；显然，如果该分支发生更改，则提交指向更改，这可能发生在获取/pull/远程更新时。)

---

编辑:下面讨论的问题已在 Git 1.8.4.3 中得到纠正；见this update .

---

不过，有一个小警告。 HEAD 是一个符号引用，指向一个分支而不是直接指向一个提交，但是 git 远程传输协议(protocol)只报告引用的提交。所以 Git 知道 HEAD 和所有其他引用指向的提交的 SHA1；然后它必须通过找到指向同一提交的分支来推断 HEAD 的值。这意味着如果两个分支碰巧指向那里，它是不明确的。 (我相信它会尽可能选择 master，然后按字母顺序回退到第一个。)你会在 git remote show origin 的输出中看到这个报告:

$ git remote show origin
* remote origin
  Fetch URL: ...
  Push  URL: ...
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    foo
    master

奇怪的是，虽然以这种方式打印的 HEAD 的概念会随着远程上的事情发生变化而改变(例如，如果 foo 被删除)，它实际上并没有更新 refs/remotes/origin/HEAD。这可能会导致非常奇怪的情况。假设在上面的示例中 origin/HEAD 实际上指向 foo，然后 origin 的 foo 分支被删除。然后我们可以这样做:

$ git remote show origin
...
HEAD branch: master
$ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/foo
$ git remote update --prune origin
Fetching origin
 x [deleted]         (none)     -> origin/foo
   (refs/remotes/origin/HEAD has become dangling)

所以即使 remote show 知道 HEAD 是 master，它也不会更新任何东西。陈旧的 foo 分支被正确修剪，HEAD 变得悬空(指向一个不存在的分支)，并且它仍然不会更新它以指向 master。如果你想解决这个问题，使用 git remote set-head origin -a，它会像上面那样自动确定 origin 的 HEAD，然后实际设置 origin/HEAD 以指向适当的远程分支。