Comment puis-je réconcilier HEAD détaché avec maître / origine?

Je suis nouveau dans les complexités de branchement de Git. Je travaille toujours sur une seule branche et je valide les modifications, puis je pousse périodiquement vers mon origine distante.

Quelque part récemment, j'ai effectué une réinitialisation de certains fichiers pour les retirer de la validation des validations, puis plus tard rebase -ipour supprimer quelques validations locales récentes. Maintenant, je suis dans un état que je ne comprends pas très bien.

Dans ma zone de travail, git logmontre exactement ce à quoi je m'attendais - je suis dans le bon train avec les commits que je ne voulais pas disparaître, et les nouveaux là-bas, etc.

Mais je viens de pousser vers le référentiel distant, et ce qui est différent - quelques commits que j'avais tués dans le rebase ont été poussés, et les nouveaux commis localement ne sont pas là.

Je pense que "master / origin" est détaché de HEAD, mais je ne suis pas sûr à 100% de ce que cela signifie, comment le visualiser avec les outils de ligne de commande et comment le corriger.

Tout d'abord, clarifions ce qu'est HEAD et ce qu'il signifie lorsqu'il est détaché.

HEAD est le nom symbolique du commit actuellement extrait. Lorsque HEAD n'est pas détaché (situation «normale» ¹ : vous avez extrait une branche), HEAD pointe en fait vers le «ref» d'une branche et la branche pointe vers le commit. HEAD est ainsi «attaché» à une succursale. Lorsque vous effectuez un nouveau commit, la branche vers laquelle pointe HEAD est mise à jour pour pointer vers le nouveau commit. HEAD suit automatiquement car il pointe simplement vers la branche.

• git symbolic-ref HEADrendements refs/heads/master
  La branche nommée «master» est extraite.
• git rev-parse refs/heads/masteryield 17a02998078923f2d62811326d130de991d1a95a
  Ce commit est la pointe ou la «tête» actuelle de la branche principale.
• git rev-parse HEADdonne aussi 17a02998078923f2d62811326d130de991d1a95a
  C'est ce que signifie être un «ref symbolique». Il pointe vers un objet via une autre référence.
  (Les références symboliques ont été initialement implémentées sous forme de liens symboliques, mais ont ensuite été transformées en fichiers simples avec une interprétation supplémentaire afin de pouvoir être utilisées sur des plates-formes qui n'ont pas de liens symboliques.)

Nous avons HEAD→ refs/heads/master→17a02998078923f2d62811326d130de991d1a95a

Lorsque HEAD est détaché, il pointe directement vers une validation, au lieu de pointer indirectement vers celle-ci via une branche. Vous pouvez penser à une TÊTE détachée comme étant sur une branche sans nom.

• git symbolic-ref HEAD échoue avec fatal: ref HEAD is not a symbolic ref
• git rev-parse HEADrenvoie 17a02998078923f2d62811326d130de991d1a95a
  Comme il n'est pas une référence symbolique, il doit pointer directement vers le commit lui-même.

Nous avons HEAD→17a02998078923f2d62811326d130de991d1a95a

La chose importante à retenir avec une HEAD détachée est que si la validation vers laquelle elle pointe n'est pas référencée (aucune autre référence ne peut l'atteindre), elle deviendra alors "suspendue" lorsque vous retirerez une autre validation. Finalement, ces validations pendantes seront élaguées via le processus de collecte des ordures (par défaut, elles sont conservées pendant au moins 2 semaines et peuvent être conservées plus longtemps en étant référencées par le reflog de HEAD).

¹ Il est tout à fait correct de faire un travail «normal» avec une TETE détachée, il vous suffit de garder une trace de ce que vous faites pour éviter d'avoir à repasser l'historique perdu du reflog.

Les étapes intermédiaires d'un rebase interactif se font avec une TETE détachée (en partie pour éviter de polluer le reflog de la branche active). Si vous terminez l'opération de rebase complète, il mettra à jour votre branche d'origine avec le résultat cumulé de l'opération de rebase et rattachera HEAD à la branche d'origine. Je suppose que vous n'avez jamais complètement terminé le processus de rebase; cela vous laissera une HEAD détachée pointant vers la validation qui a été traitée le plus récemment par l'opération de rebase.

Pour récupérer de votre situation, vous devez créer une branche qui pointe vers la validation actuellement pointée par votre HEAD détaché:

git branch temp
git checkout temp

_{(ces deux commandes peuvent être abrégées en git checkout -b temp)}

Cela rattachera votre HEAD à la nouvelle tempbranche.

Ensuite, vous devez comparer le commit actuel (et son historique) avec la branche normale sur laquelle vous vous attendiez à travailler:

git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp
git diff master temp
git diff origin/master temp

(Vous voudrez probablement expérimenter avec les options de journal: ajouter -p, laisser de côté --pretty=…pour voir le message de journal entier, etc.)

Si votre nouvelle tempbranche semble bonne, vous voudrez peut-être mettre à jour (par exemple) masterpour la signaler:

git branch -f master temp
git checkout master

_{(ces deux commandes peuvent être abrégées en git checkout -B master temp)}

Vous pouvez ensuite supprimer la branche temporaire:

git branch -d temp

Enfin, vous voudrez probablement pousser l'histoire rétablie:

git push origin master

Vous devrez peut-être ajouter --forceà la fin de cette commande pour pousser si la branche distante ne peut pas être «accélérée» vers le nouveau commit (c'est-à-dire que vous avez abandonné, ou réécrit un commit existant, ou sinon réécrit un peu d'histoire).

Si vous étiez au milieu d'une opération de rebase, vous devriez probablement la nettoyer. Vous pouvez vérifier si un rebase était en cours en recherchant le répertoire .git/rebase-merge/. Vous pouvez nettoyer manuellement le rebasage en cours en supprimant simplement ce répertoire (par exemple, si vous ne vous souvenez plus du but et du contexte de l'opération de rebase active). Habituellement, vous utiliseriez git rebase --abort, mais cela fait une réinitialisation supplémentaire que vous voulez probablement éviter (il ramène HEAD à la branche d'origine et le réinitialise au commit d'origine, ce qui annulera une partie du travail que nous avons fait ci-dessus).

Faites juste ceci:

git checkout master

Ou, si vous souhaitez conserver des modifications, procédez comme suit:

git checkout -b temp
git checkout -B master temp

J'ai rencontré ce problème et quand j'ai lu la réponse la plus votée:

HEAD est le nom symbolique du commit actuellement extrait.

J'ai pensé: Ah-ha! Si HEADest le nom symbolique du commit de paiement actuel, je peux le réconcilier masteren le rebasant contre master:

git rebase HEAD master

Cette commande:

1. vérifie master
2. identifie le parent s'engage à HEADrevenir au point HEADdivergé demaster
3. joue ces commits au-dessus de master

Le résultat final est que tous les commits qui étaient dans HEADmais pas le mastersont également master. masterreste vérifié.

Concernant la télécommande:

quelques commits que j'avais tués dans le rebase ont été repoussés, et les nouveaux commis localement ne sont pas là.

L'historique distant ne peut plus être avancé rapidement à l'aide de votre historique local. Vous devrez forcer-push ( git push -f) pour écraser l'historique distant. Si vous avez des collaborateurs, il est généralement judicieux de coordonner cela avec eux afin que tout le monde soit sur la même page.

Après avoir poussé masterà distance origin, votre branche de suivi à distance origin/mastersera mise à jour pour pointer vers le même commit que master.

Regardez ici pour une explication de base de la tête détachée:

http://git-scm.com/docs/git-checkout

Ligne de commande pour le visualiser:

git branch

ou

git branch -a

vous obtiendrez une sortie comme ci-dessous:

* (no branch)
master
branch1

Les * (no branch)spectacles que vous êtes en tête détachée.

Vous auriez pu arriver à cet état en faisant un git checkout somecommitetc. et cela vous aurait averti de ce qui suit:

Vous êtes dans l'état «HEAD détaché». Vous pouvez regarder autour de vous, apporter des modifications expérimentales et les valider, et vous pouvez annuler toutes les validations que vous effectuez dans cet état sans impact sur les branches en effectuant une autre extraction.

Si vous souhaitez créer une nouvelle branche pour conserver les validations que vous créez, vous pouvez le faire (maintenant ou plus tard) en utilisant à nouveau -b avec la commande d'extraction. Exemple:

git checkout -b nouveau_nom_branche

Maintenant, pour les mettre sur le maître:

Faites un git reflogou même juste git loget notez vos commits. Maintenant git checkout masteret git mergeles commits.

git merge HEAD@{1}

Éditer:

Pour ajouter, utilisez git rebase -inon seulement pour supprimer / tuer les commits dont vous n'avez pas besoin, mais aussi pour les modifier. Il vous suffit de mentionner «modifier» dans la liste de validation et vous pourrez modifier votre validation, puis émettre un git rebase --continuepour continuer. Cela aurait garanti que vous ne veniez jamais dans une tête détachée.

Obtenez votre commit détaché sur sa propre branche

Courez simplement git checkout -b mynewbranch.

Ensuite, exécutez git loget vous verrez que la validation est maintenant HEADsur cette nouvelle branche.

si vous venez de créer une branche principale et que vous souhaitez revenir au "développement" ou à une fonctionnalité, procédez comme suit:

git checkout origin/develop

Remarque: vérifier l' origine / développer .

Vous êtes dans un état HEAD détaché . Vous pouvez regarder autour de vous, apporter des modifications expérimentales et les valider, et vous pouvez annuler toutes les validations que vous effectuez dans cet état sans impact sur les branches en effectuant une autre extraction ...

puis

git checkout -b develop

Ça marche :)

Si vous voulez pousser votre HEAD détachée actuelle (cochez git logavant), essayez:

git push origin HEAD:master

pour envoyer votre HEAD détaché dans la branche principale à l'origine. Si votre push est rejeté, essayez d' git pull origin masterabord d'obtenir les modifications depuis l'origine. Si vous ne vous souciez pas des modifications par rapport à l'origine et qu'elles sont rejetées, car vous avez effectué un rebase intentionnel et que vous souhaitez remplacer origin / master par votre branche actuellement détachée - vous pouvez alors la forcer ( -f). Si vous avez perdu l'accès aux validations précédentes, vous pouvez toujours exécuter git reflogpour voir l'historique de toutes les branches.

Pour revenir sur une branche principale, tout en conservant les modifications, essayez les commandes suivantes:

git rebase HEAD master
git checkout master

Voir: Git: "Pas actuellement sur aucune branche." Existe-t-il un moyen simple de revenir sur une branche, tout en conservant les modifications?

J'ai trouvé cette question lors de la recherche You are in 'detached HEAD' state.

Après avoir analysé ce que j'avais fait pour arriver ici, par rapport à ce que j'avais fait dans le passé, j'ai découvert que j'avais fait une erreur.

Mon débit normal est:

git checkout master
git fetch
git checkout my-cool-branch
git pull

Cette fois, j'ai fait:

git checkout master
git fetch
git checkout origin/my-cool-branch
# You are in 'detached HEAD' state.

Le problème est que j'ai accidentellement fait:

git checkout origin/my-cool-branch

Plutôt que:

git checkout my-cool-branch

Le correctif (dans ma situation) consistait simplement à exécuter la commande ci-dessus, puis à continuer le flux:

git checkout my-cool-branch
git pull

Les éléments suivants ont fonctionné pour moi (en utilisant uniquement le maître de branche):

git push origin HEAD:master
git checkout master        
git pull

Le premier pousse la tête détachée à l'origine distante.

Le second passe au maître de branche.

Le troisième récupère la TETE qui s'attache au maître de branche.

Des problèmes peuvent survenir à la première commande si le push est rejeté. Mais cela ne serait plus un problème de tête détachée, mais concerne le fait que la tête détachée n'est pas au courant de certains changements à distance.

Je viens de rencontrer ce problème aujourd'hui et je suis presque sûr de l'avoir résolu en faisant:

git branch temp
git checkout master
git merge temp

J'étais sur mon ordinateur de travail lorsque j'ai compris comment faire cela, et maintenant je rencontre le même problème sur mon ordinateur personnel. Il faudra donc attendre jusqu'à lundi quand je serai de retour à l'ordinateur de travail pour voir exactement comment je l'ai fait.

Si vous êtes absolument sûr que HEAD est en bon état:

git branch -f master HEAD
git checkout master

Vous ne pouvez probablement pas pousser à l'origine, car votre maître a divergé de l'origine. Si vous êtes sûr que personne d'autre n'utilise le dépôt, vous pouvez forcer:

git push -f

Plus utile si vous êtes sur une branche de fonctionnalité que personne d'autre n'utilise.

Tout ce que vous avez à faire est «git checkout [nom-branche]» où [nom-branche] est le nom de la branche d'origine à partir de laquelle vous êtes entré dans un état de tête détaché. Le (détaché de asdfasdf) disparaîtra.

Ainsi, par exemple, dans la branche «dev», vous extrayez le commit asdfasd14314 ->

'git checkout asdfasd14314'

vous êtes maintenant dans un état de tête détaché

'git branch' affichera quelque chose comme ->

* (detached from asdfasdf)
  dev
  prod
  stage

mais pour sortir de l'état de tête détaché et revenir au dev ->

'git checkout dev'

puis 'git branch' listera ->

* dev
  prod
  stage

mais c'est bien sûr si vous n'avez pas l'intention de conserver des modifications par rapport à l'état de tête détachée mais je me retrouve à faire cela beaucoup pas l'intention de faire des changements mais juste de regarder un commit précédent

Comme l'a souligné Chris, j'ai eu la situation suivante

git symbolic-ref HEAD échoue avec fatal: ref HEAD is not a symbolic ref

Cependant git rev-parse refs/heads/master, pointait vers un bon commit d'où je pouvais récupérer (dans mon cas, le dernier commit et vous pouvez le voir en utilisantgit show [SHA]

J'ai fait beaucoup de choses désordonnées après cela, mais ce qui semble avoir été réparé est juste,

git symbolic-ref HEAD refs/heads/master

Et la tête est re-attachée!

Au lieu de faire git checkout origin/master

fais juste git checkout master

puis git branchconfirmera votre succursale.

J'ai eu ce problème aujourd'hui, où j'avais mis à jour un sous-module, mais je n'étais sur aucune branche. Je m'étais déjà engagé, donc le stockage, le paiement, le stockage ne fonctionneraient pas. J'ai fini par choisir le commit de la tête détachée. Donc, immédiatement après avoir commis (lorsque la poussée a échoué), j'ai fait:

git checkout master
git cherry-pick 99fe23ab

Ma pensée est allée: je suis sur une tête détachée, mais je veux être maître. En supposant que mon état détaché ne soit pas très différent de master, si je pouvais appliquer mon commit à master, je serais défini. C'est exactement ce que fait la sélection.

Si vous avez fait quelques commits au-dessus du master et que vous voulez juste "fusionner en arrière" masterlà-bas (c'est-à-dire que vous voulez masterpointer HEAD), le one-liner serait:

git checkout -B master HEAD

1. Cela crée une nouvelle branche nommée master, même si elle existe déjà (ce qui revient à se déplacer masteret c'est ce que nous voulons).
2. La branche nouvellement créée est définie pour pointer vers HEAD, où vous êtes.
3. La nouvelle branche est extraite, vous êtes donc activé par la mastersuite.

J'ai trouvé cela particulièrement utile dans le cas des sous-référentiels, qui se trouvent également être dans un état détaché assez souvent.

J'ai eu le même problème et je l'ai résolu en suivant les étapes suivantes.

Si vous devez conserver vos modifications

1. Vous devez d'abord exécuter la git checkout mastercommande pour vous remettre dans la branche principale.
2. Si vous avez besoin de garder vos changements courir juste git checkout -b changeset git checkout -B master changes

Si vous n'avez pas besoin de vos modifications

1. Pour supprimer tous les fichiers non suivis de votre exécution de branche git clean -df.

2. Ensuite, vous devez effacer toutes les modifications non mises en scène dans votre référentiel. Pour ce faire, vous devez exécutergit checkout --

3. Enfin, vous devez remettre votre branche dans la branche principale en utilisant la git checkout mastercommande.

Pour moi, c'était aussi simple que de supprimer à nouveau la branche locale, car je n'avais pas de commits locaux que je voulais pousser:

J'ai donc fait:

git branch -d branchname

Et puis vérifier à nouveau la branche:

git checkout branchname

Lorsque je me trouve personnellement dans une situation où il s'avère que j'ai apporté des modifications alors que je ne suis pas master(c'est HEAD-à- dire détaché juste au-dessus du masteret il n'y a pas de commits entre les deux), le stockage peut aider:

git stash # HEAD has same content as master, but we are still not in master
git checkout master  # switch to master, okay because no changes and master
git stash apply  # apply changes we had between HEAD and master in the first place

En termes simples, l'état HEAD détaché signifie que vous n'êtes pas extrait de HEAD (ou tip) d'une branche .

Comprendre avec un exemple

Dans la plupart des cas, une branche est une séquence de plusieurs validations comme:

Commit 1: master -> branch_HEAD (123be6a76168aca712aea16076e971c23835f8ca)

Commit 2: master -> 123be6a76168aca712aea16076e971c23835f8ca -> branch_HEAD (100644a76168aca712aea16076e971c23835f8ca)

Comme vous pouvez le voir ci-dessus en cas de séquence de validations, votre branche pointe vers votre dernière validation. Donc, dans ce cas, si vous réglez pour valider 123be6a76168aca712aea16076e971c23835f8ca, vous serez alors en état de tête détachée puisque HEAD de votre branche pointe vers 100644a76168aca712aea16076e971c23835f8ca et techniquement, vous êtes vérifié à HEAD d'aucune agence. Par conséquent, vous êtes dans l'état HEAD détaché.

Explication théorique

Dans ce blog, il indique clairement qu'un référentiel Git est un arbre de validations, chaque validation pointant vers son ancêtre avec chaque pointeur de validation est mis à jour et ces pointeurs vers chaque branche sont stockés dans les sous-répertoires .git / refs. Les balises sont stockées dans .git / refs / tags et les branches sont stockées dans .git / refs / heads. Si vous regardez l'un des fichiers, vous trouverez que chaque balise correspond à un seul fichier, avec un hachage de validation de 40 caractères et comme expliqué ci-dessus par @Chris Johnsen et @Yaroslav Nikitenko, vous pouvez consulter ces références.

Je me suis retrouvé dans un état vraiment idiot, je doute que quelqu'un d'autre le trouve utile ... mais juste au cas où

git ls-remote origin
0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b        HEAD
6f96ad0f97ee832ee16007d865aac9af847c1ef6        refs/heads/HEAD
0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b        refs/heads/master

que j'ai finalement fixé avec

git push origin :HEAD

Cela a parfaitement fonctionné pour moi:

1. git stashpour enregistrer vos modifications locales

Si vous souhaitez
git clean -df
git checkout -- .
supprimer les modifications, git clean supprime tous les fichiers non suivis (avertissement: bien qu'il ne supprime pas les fichiers ignorés mentionnés directement dans .gitignore, il peut supprimer les fichiers ignorés résidant dans les dossiers) et git checkout efface toutes les modifications non mises en scène.

2. git checkout masterpour passer à la branche principale (en supposant que vous voulez utiliser master)
3. git pullpour tirer le dernier commit de la branche master
4. git statusafin de vérifier que tout a l'air bien

On branch master
Your branch is up-to-date with 'origin/master'.

Dans mon cas, j'ai couru git statuset j'ai vu que j'avais quelques fichiers non suivis dans mon répertoire de travail.

Pour que le rebase fonctionne, je devais juste les nettoyer (car je n'en avais pas besoin).

Si vous utilisez EGit dans Eclipse: supposez que votre maître est votre principale branche de développement

• vous engager des modifications dans une branche, normalement une nouvelle
• puis tirez de la télécommande
• puis faites un clic droit sur le nœud du projet, choisissez l'équipe puis choisissez afficher l'historique
• puis faites un clic droit sur le maître, choisissez check out
• si Eclipse vous le dit, il y a deux maîtres un local une télécommande, choisissez la télécommande

Après cela, vous devriez pouvoir vous rattacher au maître d'origine.

J'ai eu le même problème. J'ai caché mes modifications avec git stashet réinitialisé la branche en local sur un commit précédent (je pensais que cela avait causé cela), puis git pullj'ai fait un et je ne détache pas cette tête maintenant. N'oubliez pas git stash applyd'avoir à nouveau vos modifications.

git checkout checksum  # You could use this to peek previous checkpoints
git status # You will see HEAD detached at checksum
git checkout master # This moves HEAD to master branch