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