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

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

我认为上面回答了您真正想知道的内容，但要继续回答您明确提出的问题......当您克隆存储库时会自动设置 origin/HEAD ，仅此而已。奇怪的是，它
不是 由像这样的命令设置的git remote update——我相信它会改变的唯一方法是你手动改变它。（通过更改，我的意思是指向不同的分支；显然，如果该分支发生更改，则它指向的提交会更改，这可能发生在
fetch/pull/remote 更新时。）

编辑 ：下面讨论的问题已在 Git 1.8.4.3
中得到纠正；看到这个更新。

不过，有一个小小的警告。HEAD 是一个符号 ref，指向一个分支而不是直接指向一个提交，但是 git 远程传输协议只报告 refs 的提交。所以 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 被删除）而改变，但它实际上并没有 update
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)

因此，即使远程显示知道 HEAD 是主控，它也不会更新任何内容。陈旧的 foo 分支被正确修剪，并且 HEAD 变得悬空（指向不存在的分支），它 仍然
没有更新它以指向 master。如果你想解决这个问题，请使用git remote set-head origin -a，它会自动确定 origin 的
HEAD，然后实际将 origin/HEAD 设置为指向适当的远程分支。