Quelle est la robustesse de Git lorsque le courant est coupé?

Un jour, j'utilisais Git (je l'utilise toujours) et l'électricité a baissé pendant que je m'engageais.

Quand je (en fait, l'électricité) est revenu, le dépôt git était corrompu. Je ne me souviens pas du nom exact, mais c'était quelque chose comme "références invalides" ou quelque chose comme ça.

Il est facile de deviner que la validation a été rompue au milieu de l'opération (je validais via IntelliJ, qui effectue automatiquement les ajouts d'index). Il était également facile de deviner qu'en réalité, «commit» n'est pas aussi ACID que l'opération SGBD du même nom.

Q : Existe-t-il un moyen de garantir que les opérations de modification de pension respectent l'atomicité? c'est-à-dire que si l'électricité baisse à nouveau et que je m'engage, j'aimerais que mon système de fichiers ne soit pas corrompu.

Je ne sais pas s'il existe un moyen de faire en sorte que les validations Git survivent à des pannes de courant parfaitement synchronisées, mais vous pourriez peut-être réparer votre référentiel.

Les objets Git sont censés être immuables, donc toutes vos anciennes validations devraient toujours être valides. Selon cette réponse , vous pouvez modifier le hachage .git/refs/heads/<branch-name>pour changer le chef de la branche sur laquelle vous travailliez sur le commit précédent (vous pouvez les voir dans .git/logs/HEAD).

Le commentaire de cette réponse indique que cette méthode "laisse toujours le référentiel dans un état cassé, mais cela permet de le récupérer". Je n'ai pas testé cela (aucune idée de comment reproduire votre situation), mais je suppose que la récupération est effectuée via git gc, cela supprimera le commit corrompu.

Le système de stockage de Git n'est pas transactionnel, il y a donc certainement une chance qu'un problème matériel puisse laisser les choses dans un état incohérent. D'un autre côté, Git est également très rapide, il faut donc être vraiment malchanceux pour être touché par des problèmes de type «coupure de courant» (les problèmes systématiques avec le disque sont autre chose). La vitesse vient en partie précisément du fait qu'elle n'est pas transactionnelle; les transactions sont vraiment assez chères car elles doivent attendre la confirmation du disque qu'elles ont écrit les données. (Les bases de données font toutes sortes de choses pour essayer de cacher ce coût, mais en fin de compte, elles en paient toujours le prix. Certains des DVCS concurrents sont transactionnels, et oui, ils sont un peu plus lents sur le même matériel que git.)

Dans le pire des cas - une défaillance totale catastrophique du disque (ce que j'ai vu se produire) - le seul moyen pour tout DVCS de récupérer est d'utiliser le fait qu'il est distribué. Si vous avez poussé vos changements jusqu'à très récemment vers un autre système et qu'ils les ont partagés avec de nombreux hôtes différents, la récupération consiste simplement à utiliser l'un de ces autres emplacements comme source d'artefact, un emplacement pour extraire vos branches ( même si ce n'est que temporairement). De cette façon, vous retrouvez l'historique des branches intéressantes et vous pourrez recommencer à travailler très rapidement; tout ce qui efface de nombreuses copies distribuées de votre repo à la fois est soit un désastre du genre où vous ne vous inquiétez pas de la programmation par la suite (pensez à un impact majeur de météorite) ou est une action pure et simple de l'ennemi. (Essayez de ne pas vous faire de tels ennemis…) Cela contraste totalement avec les systèmes non distribués, où perdre le serveur central qui héberge tout est un coup fatal.