Detached HEAD dans Git : garder ses commits

Exemple et conditions

Cet exemple utilise un checkout temporaire d’une ancienne version et deux nouveaux commits à conserver comme correction. Cela diffère d’un rebase actif ou d’un submodule volontairement détaché. Lisez status et terminez ou annulez consciemment toute opération active avant d’appliquer ce parcours.

Examiner avant de modifier

Dans le cas détaché ordinaire, branch --show-current reste vide. Status explique l’état et log présente l’historique commité actuel. Notez l’identifiant de HEAD. Une sortie vide ne signifie ni absence de branches ni fichiers non suivis : la référence et le contenu de l’arbre répondent à des questions différentes.

git status
git branch --show-current
git log -3 --oneline
git rev-parse HEAD

Garder une référence ou un checkout séparé

Créez rescue/detached avec switch -c sur le commit voulu. La branche maintient cet historique accessible, mais ne transforme pas les modifications locales en commit. Examinez et enregistrez celles-ci séparément si nécessaire. Prenez un nom nouveau, sans remplacer une branche existante par une option de force.

git switch -c rescue/detached
git branch --show-current

Premier parcours

Vérifiez nom, commits et patch. Continuez sur cette branche ou intégrez la correction avec merge ou cherry-pick : cherry-pick copie un changement dans un nouveau commit ; merge joint les historiques. Choisissez selon la tâche et contrôlez le résultat. Sortir de detached HEAD ne nécessite pas de push automatique.

git log -3 --oneline --decorate
git show --stat HEAD

Choisir l’autre résultat consciemment

Si vous êtes déjà parti, examinez le reflog local et les candidats avec show. Choisissez selon patch et parent, puis créez rescue/recovered sur l’identifiant vérifié. VERIFIED_COMMIT est un marqueur à remplacer. HEAD@{1} n’est pas toujours le commit perdu : les opérations suivantes peuvent déplacer l’entrée pertinente.

git reflog --date=iso
git show VERIFIED_COMMIT
git branch rescue/recovered VERIFIED_COMMIT

Limites et exceptions

Reflog enregistre les mouvements de références locales ; ce n’est pas une archive distante. Ses entrées et les objets inaccessibles peuvent expirer ou être supprimés. Les modifications non commitées n’y ont jamais été enregistrées comme commits. Cherchez une copie antérieure, comme un backup d’éditeur ou un stash vérifié, sans promettre de les reconstruire par reflog.

Conflits et nettoyage

Un submodule utilise souvent detached HEAD pour consommer le commit fixé par le parent. C’est normal pour une dépendance. Pour développer le dépôt enfant, créez sa propre branche à l’intérieur et suivez son processus. Une branche du parent ne nomme pas automatiquement les commits de l’enfant : leurs références et historiques sont séparés.

Vérifier le résultat

Avant de supprimer le secours, vérifiez qu’une branche durable ou un merge revu atteint encore les commits voulus. Contrôlez état et patch sur la cible et gardez la référence pendant la revue. Un nom de branche conserve l’historique commité ; ce n’est pas une seconde copie physique de tous les fichiers ni une validation des tests.

git log --oneline --decorate rescue/detached
git status --short

Questions fréquentes

Est-ce une erreur ? Non si vous inspectez volontairement un commit, tag ou submodule fixé. Peut-on commiter ? Oui, mais nommez l’historique avant de partir. Récupérer plus tard ? Parfois, si les objets et preuves locales existent encore ; examinez les candidats sans garantir leur conservation permanente.

Examiner l’opération dans FluxGit

Utilisez l’historique visuel et la vue des modifications de FluxGit pour examiner l’opération et les commits concernés. Gardez les vérifications de branche, de partage et de fichiers locaux de cet exemple. La page de téléchargement présente les builds et plateformes disponibles.

Références officielles Git

• git-switch
• git-reflog
• git-branch