Notez d'abord que votre question montre un peu de malentendu. origin / HEAD représente la branche par défaut sur le distant , c'est-à-dire le HEAD qui se trouve dans ce référentiel distant que vous appelez origin. Lorsque vous changez de succursale dans votre dépôt, cela ne change rien. Il en va de même pour les succursales éloignées; vous pourriez avoir masteret origin/masterdans votre référentiel, où origin/masterreprésente une copie locale de la masterbranche dans le référentiel distant.
HEAD d'origine ne changera que si vous ou quelqu'un d'autre le modifiez réellement dans le référentiel distant , ce qui ne devrait pratiquement jamais se produire - vous voulez que la branche par défaut d'un dépôt public reste constante, sur la branche stable (probablement master). origin / HEAD est une référence locale représentant une copie locale de HEAD dans le référentiel distant. (Son nom complet est refs / télécommandes / origine / HEAD.)
Je pense que ce qui précède répond à ce que vous vouliez réellement savoir, mais pour aller de l'avant et répondre à la question que vous avez explicitement posée ... origin / HEAD est défini automatiquement lorsque vous clonez un référentiel, et c'est à peu près tout. Bizarrement, ce n'est pas défini par des commandes telles que git remote update- je pense que la seule façon dont cela changera est si vous le modifiez manuellement. (Par changement, je veux dire pointer vers une branche différente; évidemment, le commit indique des changements si cette branche change, ce qui peut se produire lors de la récupération / extraction / mise à jour à distance.)
Edit : Le problème discuté ci-dessous a été corrigé dans Git 1.8.4.3 ; voir cette mise à jour .
Il y a cependant une petite mise en garde. HEAD est une référence symbolique, pointant vers une branche au lieu de directement vers un commit, mais les protocoles de transfert à distance git ne rapportent que les validations pour les refs. Donc Git connaît le SHA1 du commit pointé par HEAD et toutes les autres références; il doit ensuite déduire la valeur de HEAD en trouvant une branche qui pointe vers le même commit. Cela signifie que si deux branches pointent là, c'est ambigu. (Je crois qu'il choisit le maître si possible, puis revient au premier par ordre alphabétique.) Vous verrez cela signalé dans la sortie de 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
Curieusement, bien que la notion de HEAD imprimée de cette façon changera si les choses changent sur la télécommande (par exemple si foo est supprimé), elle ne se met pas à jour refs/remotes/origin/HEAD. Cela peut conduire à des situations vraiment étranges. Dites que dans l'exemple ci-dessus, origin / HEAD pointait en fait vers foo, et la branche foo de l'origine a ensuite été supprimée. Nous pouvons alors faire ceci:
$ 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)
Ainsi, même si Remote Show sait que HEAD est maître, il ne met rien à jour. La branche foo périmée est correctement élaguée et HEAD devient pendante (pointant vers une branche inexistante), et elle ne la met toujours pas à jour pour pointer vers master. Si vous voulez résoudre ce problème, utilisez git remote set-head origin -a, qui détermine automatiquement HEAD d'origine comme ci-dessus, puis définit en fait l'origine / HEAD pour qu'il pointe vers la branche distante appropriée.
refs/origin/HEAD. Il ne s'agit pas de la façon dont la propre référence symbolique d'un référentielHEADest définie.