Pourquoi «origin / HEAD» est-il affiché lors de l'exécution de «git branch -r»?

Quand vous exécutez, git branch -rpourquoi les flammes listent-elles origin/HEAD? Par exemple, il existe un dépôt distant sur GitHub, disons, avec deux branches: master et awesome-feature. Si je le git clonesaisis et que j'entre dans mon nouveau répertoire et que je répertorie les branches, je vois ceci:

$ git branch -r
origin/HEAD
origin/master
origin/awesome-feature

Ou quel que soit l'ordre dans lequel il se trouverait (alpha? Je simule cet exemple pour garder secrète l'identité d'un repo innocent). Alors, quel est le HEADproblème? Est-ce ce que la dernière personne à pushavoir HEADpointé quand ils ont poussé? N'est-ce pas toujours ce qu'ils ont été push? HEADs se déplacer ... pourquoi est-ce que je me soucie de ce que quelqu'un a HEADpointé sur une autre machine?

Je suis juste en train de comprendre le suivi à distance et autres, c'est donc une confusion persistante. Merci!

EDIT: J'avais l'impression que les dépôts distants dédiés (comme GitHub où personne ne va ssh et travailler sur ce code, mais seulement tirer ou pousser, etc.) n'avaient pas et ne devraient pas avoir de HEAD parce qu'il y avait, fondamentalement, pas de copie de travail. Non?

@robinst est correct.

Dans git, vous pouvez sélectionner quelle branche est extraite par défaut (c'est-à-dire lorsque vous clonez). Par défaut, origin/HEADpointera vers cela.

Sur GitHub, vous pouvez modifier cela dans les paramètres d'administration de votre dépôt GitHub. Vous pouvez également le faire à partir de la ligne de commande via

git remote set-head origin trunk

ou supprimez-le complètement via

git remote set-head origin -d

Exemple . Regardez la liste déroulante «Changer de branche». trunkest vérifié, donc origin/HEADsuit trunk.

La raison pour laquelle un référentiel nu peut avoir un HEAD, c'est parce qu'il détermine quelle branche est initialement extraite après un clone du référentiel.

Normalement, HEAD pointe vers master, et c'est la branche qui est extraite lorsque les gens clonent le référentiel. Le définir sur une autre branche (en modifiant HEAD dans le référentiel nu) entraîne l'extraction de cette branche lors du clonage.

J'avais l'impression que les dépôts distants dédiés (comme GitHub où personne ne ssh et ne travaillera sur ce code, mais seulement tirer ou pousser, etc.) n'avaient pas et ne devraient pas avoir de HEAD parce qu'il n'y avait, fondamentalement, aucun travail copie. Non?

J'ai eu exactement la même impression que vous l'avez dit.

Et je ne peux même pas supprimer cette branche de suivi à distance d'origine / HEAD clonée à partir de github en faisant

git branch -d -r origin/HEAD

Cela n'a eu aucun effet.

Quelqu'un peut-il me dire comment supprimer cette branche de suivi à distance d'origine / HEAD?

mettre à jour

Bien que je n'ai pas trouvé pourquoi il y a une origine / HEAD créée lors du clonage à partir de github, je trouve un moyen de le supprimer.

La nouvelle version de git fournit

git remote set-head <name> -d

pour supprimer le pointeur HEAD inutile de la branche de suivi à distance.

Et nous pouvons également changer le nom stupide par défaut 'origin' en ce que nous voulons en utilisant

git remote rename origin <new_name>

J'espère que cela peut vous aider. :)

Vous avez raison de dire que pousser vers des dépôts distants dédiés fonctionne beaucoup mieux lorsqu'ils sont «nus», c'est-à-dire lorsqu'ils n'ont pas de répertoires de travail. L'architecture de Git est conçue pour la mise à jour par des correctifs ou pull( fetch), ce qui est logique dans un VCS distribué. Comme le disent les documents quelque part, pousser vers une branche qui est actuellement extraite peut entraîner des "résultats inattendus" .

La HEAD fait partie des exigences d'un référentiel valide. La disposition du référentiel Git dit, en partie:

HEAD

A symref (see glossary) to the refs/heads/ namespace describing the currently active  
branch. It does not mean much if the repository is not associated with any working tree  
(i.e. a bare repository), but a valid git repository must have the HEAD file; some  
porcelains may use it to guess the designated "default" branch of the repository  
(usually master). It is legal if the named branch name does not (yet) exist.

Vous allez donc voir HEAD dans la liste des branches, même si "ça ne veut pas dire grand chose ..."

Si "origin" est un référentiel distant, alors origin / HEAD identifie la branche par défaut sur ce référentiel distant.

Exemple:

$ git remote show
origin
$ git remote show origin
* remote origin
  Fetch URL: git@github.com:walkerh/pipe-o-matic.git
  Push  URL: git@github.com:walkerh/pipe-o-matic.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (fast-forwardable)

Notez la ligne qui dit "HEAD branch: master". C'est là que le référentiel distant permet aux clients de savoir quelle branche retirer par défaut.

Il y a toujours un HEAD qui pointe vers la branche actuellement extraite sur le dépôt distant (qui peut ou non être maître). Même les référentiels distants ont des branches actuelles. Habituellement, c'est maître, et du haut de ma tête, je ne vois aucune raison pour laquelle on voudrait le changer, mais cela peut être changé.

Je suppose que quelqu'un a poussé une branche et l'a appelée HEAD:

git push origin HEAD