Récupération et le reflog

Git ne perd presque jamais rien. Le difficile, c'est de le retrouver.

Reflog

Chaque mouvement de HEAD — et de chaque branche — avec ce qui l'a provoqué : extraction, réinitialisation, rebase, amendement, un fetch forcé. Depuis n'importe quelle entrée passée, vous pouvez l'extraire, en créer une branche, ou y faire un reset hard.

C'est le bouton « je viens de réinitialiser la mauvaise branche ».

Instantanés de travail en cours

Le travail non validé est la seule chose que le reflog ne peut pas sauver : Gitcito en prend donc des instantanés. La copie de travail entière — fichiers modifiés, indexés et non suivis — validée via un index jetable et épinglée sous refs/gitcito/wip. Ni votre index réel ni votre liste de remisages ne sont touchés.

Trois choses en prennent un :

Le garde-fou est celui qui compte : le moment où le travail se perd généralement à jamais, c'est la seconde qui suit un abandon que vous ne vouliez pas. Avec le garde-fou activé, cet état est un instantané — ouvrez la liste, cliquez sur restaurer, respirez à nouveau.

Sélectionnez un instantané pour voir les fichiers qu'il a capturés, prévisualiser le changement de n'importe quel fichier, et restaurer un seul fichier ou toute la copie de travail. La restauration copie les fichiers de l'instantané par-dessus les copies actuelles — un instantané de garde-fou est pris d'abord, donc une restauration est elle-même annulable.

Limites à connaître. Un passage du minuteur ou du garde-fou qui ne trouve rien de nouveau n'enregistre rien. La restauration écrase et recrée des fichiers, mais ne supprime jamais un fichier créé après l'instantané. Les fichiers ignorés ne sont pas capturés. Les instantanés sont des références cachées locales : jamais poussées, à l'abri de git gc, les 50 plus récentes conservées.

Bisect guidé

Marquez les commits bons et mauvais, regardez la plage se resserrer, atterrissez sur le premier commit défectueux. Gitcito suit combien d'étapes il reste, pour que vous sachiez si vous êtes à deux questions de la réponse ou à dix.

Laisser une commande décider

Une fois la plage amorcée, Laisser une commande décider confie toute la recherche à git bisect run. Git extrait chaque candidat, exécute votre commande, et lit son code de sortie :

Une suite de tests parle déjà cette langue, ce qui explique pourquoi npm test est généralement toute la réponse. Gitcito propose les propres scripts de ce projet en remplissage d'un clic, diffuse la sortie pendant l'exécution, et atterrit sur le premier commit défectueux sans que vous répondiez à la moindre question.

Ce à quoi il faut faire attention. La commande s'exécute sur chaque commit que git teste : une commande qui déploie, publie ou écrit en dehors du dépôt le fera donc plusieurs fois de suite. Tenez-vous-en à quelque chose qui ne fait que lire et rapporter. Arrêter tue l'exécution et laisse la session ouverte, pour que vous puissiez continuer à marquer à la main ; Abandonner met fin au bisect entièrement.

Une commande qui échoue pour une raison sans rapport — une dépendance manquante à ce point de l'histoire, par exemple — marque un bon commit comme mauvais et envoie la recherche au mauvais endroit. Sortir avec 125 depuis un script enveloppe est la porte de sortie que git prévoit pour cela.

Un fichier de verrou oublié

Git pose un fichier .lock à côté de ce qu’il s’apprête à écrire et le retire quand l’écriture aboutit. Un processus qui meurt en le tenant — un éditeur qui plante, un terminal fermé pendant git commit, un fetch tué en pleine purge de références distantes — laisse le verrou derrière lui, et dès lors toute écriture échoue sur la même ligne :

error: could not delete references: cannot lock ref 'refs/remotes/origin/x':
Unable to create '…/refs/remotes/origin/x.lock': File exists.

Le dépôt n’est pas abîmé. Un fichier est simplement en travers du chemin.

Gitcito réessaie d’abord quelques fois, car un verrou tenu par un git en cours se libère généralement en quelques millisecondes. Sinon, l’échec ouvre une boîte de dialogue au lieu d’un mur de texte : tous les verrous encore sur le disque, l’âge de chacun, et un bouton qui les supprime et relance l’action qui avait échoué.

L’âge fait tout l’argument. Un verrou de moins de 30 secondes est présumé appartenir à un git encore au travail, et Gitcito refuse de le supprimer — il propose d’attendre et de réessayer. Les plus vieux sont proposés à la suppression, du plus ancien au plus récent, et la boîte de dialogue dit franchement quoi vérifier avant d’accepter : qu’aucun éditeur, terminal ou autre client Git ne travaille dans ce dépôt en ce moment. Supprimer un verrou sous une écriture vivante, c’est ainsi qu’un index se déchire.

Le balayage couvre le répertoire git du dépôt et son répertoire commun : les verrous d’un arbre de travail lié sont donc trouvés aussi. Les sous-modules sont ignorés — ils appartiennent à un autre dépôt et se nettoient en l’ouvrant.

Annuler / rétablir

La plupart des opérations empilent une entrée sur une pile d'annulation : ⌘Z défait donc la dernière, là où git le permet.

Voir aussi : Ce qui a changé depuis · Remisages