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   , 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 : précédemment    - un animal pelucheux, cat    —comment les gens écoutaient de la musique, et cd    —quelques onomatopées, grep  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   - 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. stockant tout  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   qui est recommandée pour changer de branche. La façon dont j'ai l'habitude de le faire (   + 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. git switch git checkout  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 à   . Et l'ID complet est   . 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 : 0828ae1 0828ae10b20500fbc777cc40aa88feefd123ea5e  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   sur la machine, tout exploit de sécurité serait extrêmement dangereux. exécuté  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   ). À cette époque, j'utilisais   au travail et   é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. jeu 7 avril 15:13:13 2005 -0700 SVN Mercurial  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   pour obtenir des mises à jour sur mon contenu axé sur Git. ici  Également publié   . ici

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Learning

2022 - the Greatest Storyteller

Newsletter

Senior JS developer

Cet audio est produit dans la langue originale de l'histoire !

Pourquoi Git est-il si compliqué

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps