Pourquoi Git est-il si compliqué

Lorsque vous apprenez à programmer, les gens recommandent souvent d'apprendre Git. En théorie, cela semble simple : un programme pour suivre les modifications de votre code qui vous aide à restaurer les versions précédentes du code lorsque vous en avez besoin. De plus, c'est un outil qui est utilisé presque partout dans l'industrie. En pratique… Git peut être pour le moins déroutant.

Pourquoi doit-il en être ainsi ?

Interface de ligne de commande—CLI

La plupart des utilisateurs quotidiens d'ordinateurs ne sont pas habitués au luxe des interfaces textuelles. J'appelle cela du luxe, car comme je l'ai écrit précédemment , il présente de gros avantages, même s'il faut parfois un certain temps pour s'habituer à l'expérience utilisateur. Donc, si vos associations correspondent à celles de la liste :

• cat - un animal pelucheux,
• cd —comment les gens écoutaient de la musique, et
• grep —quelques onomatopées,

alors il y a de fortes chances que votre première expérience avec Git ait la difficulté supplémentaire d'apprendre les bases de la ligne de commande. Quelque chose que Windows 95 et ses semblables vous ont enlevé.

Objectifs de conception de Git

Git n'a jamais été conçu pour être simple. Il a été conçu avec différents objectifs en tête : des objectifs plus importants et plus stimulants également.

Stockage sécurisé des données enregistrées

Git est censé toujours vous rendre les données exactement telles qu'elles ont été enregistrées OU vous faire savoir que le référentiel est corrompu. Et il fait un travail incroyable avec lui - vous pouvez être sûr que l'état que vous obtenez lors de la vérification d'un commit est exactement tel que son auteur l'a voulu. Bien sûr, cela suppose qu'ils savaient ce qu'ils faisaient.

Comment Git parvient-il à une si bonne sécurité des données ? Il le fait de manière intelligente en stockant tout - les commits, les dossiers et les fichiers. Chaque objet est identifié par un hachage cryptographique de son contenu, un nombre généré en fonction du contenu de l'objet, qui changera si quelque chose à l'intérieur des fichiers est modifié. Étant donné que les références entre les objets sont également hachées, il n'y a presque aucun moyen de falsifier l'intérieur d'un référentiel sans que Git remarque que quelque chose ne va pas. Et même dans ces cas, le code significatif serait remplacé par un charabia de texte long.

Travailler sur des réseaux non sécurisés et avec des participants non fiables

Comme tout est identifié par des hachages cryptographiques, Git n'a pas besoin de faire confiance à une grande partie du réseau pour conserver les données intactes. Git est protégé contre les attaques man-in-the-middle : il est impossible que quelqu'un puisse injecter du code significatif entre deux nœuds de Git. Bien sûr, si quelqu'un peut lire des commits auxquels il n'était pas destiné, c'est aussi un problème, mais avec des conséquences moins dangereuses que les attaquants qui injectent du code dans la base de code.

Pour une couche de sécurité supplémentaire, Git propose la signature de commits, un moyen supplémentaire de s'assurer que le commit a été rédigé par la personne qui est définie comme son auteur.

Maintien de la rétrocompatibilité

L'interface Git est plus compliquée qu'elle ne devrait l'être car elle respecte les vieilles habitudes de ses utilisateurs. J'ai appris Git en 2011, et jusqu'à la semaine dernière, je n'avais pas remarqué qu'il y avait une nouvelle commande git switch qui est recommandée pour changer de branche. La façon dont j'ai l'habitude de le faire ( git checkout + divers drapeaux) fonctionne toujours bien. Git donne la priorité aux utilisateurs plus âgés et à leurs habitudes plutôt qu'à la simplicité pour les nouveaux utilisateurs, ce qui nous amène au point suivant.

Expérience utilisateur pour les super-utilisateurs

Git est un outil conçu pour les super-utilisateurs. Il a été écrit par Linus Torvalds pour gérer la base de code Linux, ce n'est pas une tâche de débutant. Les principaux utilisateurs de Git développent des systèmes d'exploitation, ont des décennies d'expérience en programmation et vivent à l'intérieur de la ligne de commande. Toutes les utilisations à côté de cela sont accidentelles et ne sont pas la principale préoccupation des personnes développant Git.

Compromis de simplicité

Lorsque vous concevez des systèmes, rien n'est gratuit, y compris la simplicité pour les utilisateurs.

Cacher la complexité

Lorsque vous traitez un problème intrinsèquement complexe, vous facilitez les solutions en faisant abstraction de la complexité. Est-ce parti? Non, c'est juste caché à l'utilisateur. Par exemple, dans le cas d'une connexion Internet, moi et la plupart comprenons la qualité de la connexion uniquement en nombre de barres à 📶 :

• moins c'est mal
• plus c'est bien

C'est suffisant pour utiliser Internet, mais il est difficile de comprendre et de résoudre les problèmes de connexion.

Git se concentre sur l'exposition de toute la complexité liée à la modification de fichiers en parallèle et à la synchronisation de manière asynchrone. À l'opposé, vous avez un accès direct au disque partagé. C'est facile à utiliser, mais que se passera-t-il lorsque deux personnes essaieront de modifier le même fichier en même temps ? L'un aura de la chance et conservera ses modifications, et l'autre perdra tout. Pas un bon flux de travail, surtout si les modifications perdues valent des heures de travail coûteux. Parce que Git expose à l'utilisateur tous les problèmes qui peuvent apparaître dans cette situation, il permet de résoudre les conflits dans les fichiers de manière intelligente, ce qui nécessite dans certains cas que les utilisateurs le fassent manuellement.

Facile vs sécurisé

Une autre partie de Git qui déroute les utilisateurs est les identifiants de validation qui sont très longs, ainsi que les numéros impossibles à mémoriser. Même sous leur forme abrégée et conviviale, ils ressemblent à 0828ae1 . Et l'ID complet est 0828ae10b20500fbc777cc40aa88feefd123ea5e . Pourrions-nous n'avoir que des chiffres dans l'ordre à la place, ou n'utiliser que des noms de branche ? Le problème est que les ID de commit sont des hachages qui garantissent l'intégrité des données - ils garantissent que le commit X sur ma machine est le même que le commit X sur la télécommande ou sur votre machine. Et des décalages entre eux peuvent apparaître pour différentes raisons :

• intentionnel - rebasage, modification, écrasement ou toute autre opération modifiant l'historique
• involontaire - une erreur ou une attaque sur la base de code

En simplifiant l'interface et en masquant le formulaire d'ID de validation, l'utilisateur supprimerait la possibilité pour l'utilisateur de comprendre ce qui se passe sur la base de code qu'il exécute sur sa machine. Et parce que le code est par définition exécuté sur la machine, tout exploit de sécurité serait extrêmement dangereux.

Est-ce la bonne approche ?

Quand j'apprenais Git, c'était encore une nouveauté - je l'apprenais en 2011, et Git a été créé en 2005 (le premier commit date du jeu 7 avril 15:13:13 2005 -0700 ). À cette époque, j'utilisais SVN au travail et Mercurial était souvent considéré comme une alternative plus conviviale à Git. Avez-vous entendu ces noms récemment? Git a presque complètement dominé le marché du contrôle de version. Il a gagné en popularité avec la montée en puissance de GitHub, mais même s'il est difficile pour les débutants, c'est un outil très efficace, et il est là pour rester.

Que faire en tant que programmeur débutant ?

Mon conseil est de l'apprendre le plus tôt possible. Il est très peu probable que Git devienne bientôt plus simple. Ou jamais. Les systèmes de contrôle de version en général vous évitent beaucoup de maux de tête pendant que vous programmez. Je ne peux pas imaginer être efficace avec le travail avec du code si vous avez du mal à déplacer les versions de votre base de code. Bien apprendre Git vous aidera à vous concentrer sur les défis du code au lieu de vous débattre avec des fichiers perdus ou de résoudre les soi-disant « problèmes Git », qui sont presque toujours des personnes qui gâchent elles-mêmes leur référentiel.

En plus de cela, apprendre Git est devenu un rite de passage pour les nouveaux développeurs. En tant que développeur, vous devez l'utiliser, et Git vous rendra la vie misérable si vous essayez de l'utiliser sans bien le comprendre. Le choix judicieux est de l'apprendre selon vos conditions et de ne pas attendre que les commentaires des réviseurs ou les problèmes de code vous obligent à l'apprendre tout en assumant d'autres responsabilités en même temps.

Comment en savoir plus ?

Si vous souhaitez en savoir plus sur Git, inscrivez-vous ici pour obtenir des mises à jour sur mon contenu axé sur Git.