Обратите внимание, что ваш вопрос показывает небольшое недопонимание. origin / HEAD представляет ветку по умолчанию на удаленном , то есть HEAD, который находится в том удаленном хранилище, которое вы называете origin. Когда вы переключаете филиалы в своем репо, вы не влияете на это. То же самое верно для удаленных филиалов; в вашем репо могут быть master и origin/master, где origin/master представляет локальную копию ветви master в удаленном репозитории.
HEAD источника будет меняться только в том случае, если вы или кто-то еще действительно измените его в удаленном репозитории , что в принципе никогда не должно происходить - вы хотите, чтобы ветка по умолчанию публичное репо оставалась постоянной в стабильной ветке ( наверное мастер). origin / HEAD - это локальная ссылка, представляющая локальную копию HEAD в удаленном хранилище. (его полное имя - refs / remotes / origin / HEAD.)
Я думаю, что вышеизложенное отвечает на то, что вы на самом деле хотели знать, но чтобы продолжить и ответить на вопрос, который вы явно задали ... origin / HEAD устанавливается автоматически, когда вы клонируете репозиторий, и это все. Как ни странно, это не , установленное такими командами, как git remote update - я верю, что единственный способ изменить это, если вы измените его вручную. (Под изменением я подразумеваю указание на другую ветвь; очевидно, что при коммите это указывает на изменения, если эта ветвь изменяется, что может произойти при выборке / извлечении / удаленном обновлении.)
Редактировать : проблема, описанная ниже, была исправлена в Git 1.8.4.3 ; см это обновление .
Однако есть крошечная оговорка. HEAD - это символьная ссылка, указывающая на ветку, а не непосредственно на коммит, но протоколы удаленной передачи git сообщают только о фиксациях для ссылок. Так что Git знает SHA1 коммита, на который указывает HEAD и все другие ссылки; Затем он должен определить значение 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, а ветка foo origin была затем удалена. Затем мы можем сделать это:
$ 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, который автоматически определяет HEAD источника как указано выше, а затем фактически устанавливает origin / HEAD для указания на соответствующую удаленную ветвь.