La partie 1 de cet article vous a présenter les raisons qui rendent le passage difficile de Subversion à Git tout en expliquant comment contourner ces difficultés. Mais la tâche n’est pas terminée et il reste beaucoup à dire alors…
Suite
Dans la PARTIE 1 de l’article j’expliquais mon parcours, ma conversion à Git et les difficultés que j’ai rencontrées, plus d’ordre psychologiques que techniques au final. Le principal problème est qu’il ne faut pas aborder Git comme un nouveau logiciel avec de nouvelles commandes à apprendre pour mimer Subversion. Il faut aborder Git avant tout sous la forme d’un changement de paradigme. Une vision sur cette fonction de gestion de code source radicalement différente. Les fonctions sont assez semblables, ce qui entretient encore plus cette difficulté de comprendre la nature réelle du changement.
J’ai présenté une partie de ces changements de point de vue dans la Partie 1 je n’y reviendrais pas ici, au contraire je vais tout simplement continuer… Lisez la partie 1 avant la partie 2, cela me semble vraiment préférable pour comprendre la progression logique et pédagogique de l’article complet.
De chaque action visible à ne partager que l'essentiel
Avec un référentiel centralisé et la plupart des actions effectuées directement sur celui-ci, un utilisateur de Subversion montre à tous les membres de l'équipe ce qu'il fait tout le temps, même ses erreurs, ses commits inutiles pour corriger une faute d'orthographe dans un commentaire. Même lorsqu'un utilisateur travaille dans une branche de Subversion, les modifications apportées sont toujours visibles et disponibles pour tous les autres utilisateurs.
Cependant sous Git la plupart des actions étant menées sur un référentiel local un développeur n'a qu'à montrer que ce qui est important pour le reste de l'équipe. Un développeur peut créer autant de branches locales que nécessaire et expérimenter différentes idées. Il peut également annuler les modifications pour récupérer les versions précédentes ou extraire des modifications d'autres endroits pour obtenir ce dont il a besoin.
Un développeur n'est pas obligé de montrer tout son historique aux autres développeurs de l'équipe. Il peut limiter ce qui est partagé à ce qui est important, qu'il s'agisse d'un commit unique englobant une fonctionnalité entière ou d'un petit nombre de commits construits à partir d'un grand nombre de branches et d'idées. Ceci fournit au développeur une certaine liberté et une flexibilité que Subversion ne peut permettre : travailler à sa manière sans se soucier de la façon dont les autres travaillent. Et surtout sans polluer le repository central…
Du Commit à Stage et Commit
Subversion et Git exigent que vous ajoutiez un fichier au référentiel afin que celui-ci sache comment le suivre. Une validation dans Subversion est une étape unique : la validation avec un éventuel message de validation. Cependant, une validation dans Git est un processus en deux étapes (avec un raccourci possible). Une fois qu'un fichier a été ajouté à Git pour le suivi, les modifications apportées à ce fichier doivent être mises en Stage avant de pouvoir être committées.
La mise en Stage d'un fichier prend son état actuel et le place dans une zone de mise en attente spéciale de Git, où il peut être validé ou subir quelques opérations. Toute modification supplémentaire apportée au fichier impose de le « stagé » (staged) à nouveau, sinon Git ne validera pas ces modifications. Une fois qu'un fichier ou un groupe de fichiers ont été préparés, un commit avec son message de validation peut être effectué. Seuls les fichiers qui ont été stagés seront validés. Si vous stagez un fichier pour validation par erreur ou si vous avez besoin de le retirer de la zone de stockage intermédiaire, vous pouvez le supprimer en effectuant un git reset du fichier.
Des numéros de révision aux identifiants SHA-1
Une validation dans une branche ou le trunk de Subversion incrémentera le numéro de révision du référentiel. Toute personne qui fera ensuite un commit dans le référentiel recevra l’incrément suivant du numéro de révision. Cela fonctionne car il existe un seul référentiel sur lequel travaillent tous les utilisateurs et les validations ne peuvent être effectuées que sur ce référentiel.
Au lieu d'un numéro de révision incrémentiel, Git utilise un algorithme de hachage sécurisé (SHA1) pour créer un identifiant unique pour chaque validation.
Sous Git chaque utilisateur ayant son propre référentiel et la possibilité de se connecter à plusieurs référentiels distants pour partager du code, les numéros de révision incrémentiels ne seraient pas suffisants. Rien ne garantit qu'un utilisateur spécifique extrairait un commit spécifique dans son référentiel local. Au lieu d'un numéro de révision incrémentiel, Git utilise ainsi un algorithme SHA-1 pour créer un identifiant unique pour chaque validation.
L'identifiant d'un commit individuel est une série de 40 nombres et caractères hexadécimaux créant un identifiant unique à l'aide de l'algorithme SHA-1. Git génère l'ID en fonction du contenu de la validation, de son ascendance et d'autres points de données. Ce code sert à marquer la révision comme dans Subversion mais en plus Git l'utilise pour vérifier l'intégrité de la validation. Si l'ID ne correspond pas à ce qui est dans la validation, alors Git considérera que la validation est corrompue. Une sécurisation des données absente de Subversion.
Lorsque vous travaillez avec des commandes Git nécessitant un ID de validation, vous devez uniquement fournir suffisamment de longueur de l’ID de validation pour rechercher la validation en question, généralement les 6 à 8 premiers caractères de l'identifiant. La commande git log donne l’historique des dernières validations.
Des conflits de métadonnées et d'arbres aux ascendants
La plupart des utilisateurs de Subversion ont rencontré des conflits d'arborescence causés par les métadonnées stockées par Subversion avec des fichiers et des dossiers. Subversion utilise ces métadonnées pour garder une trace de l'origine d'une révision et fournit certaines données nécessaires à des fonctionnalités telles que la réintégration automatique d'une branche. Cependant les métadonnées sont facilement cassées lorsque plusieurs utilisateurs travaillent sur les mêmes fichiers et dossiers et lorsque la création de branches et la fusion entrent en jeu. Le résultat final est un conflit d'arborescence, que de nombreux développeurs ignorent ou rétablissent simplement, ce qui aggrave le problème.
En revanche, Git n'a pas besoin de stocker de métadonnées sur des fichiers et des dossiers individuels pour savoir d'où ils viennent. Au lieu de cela, Git stocke l'ascendance à l'intérieur du référentiel lui-même, liée aux commits individuels. C'est l'ascendance des commits qui donne à Git log son apparence de ligne de transit tel que la plupart des shell le montrent.
Par exemple, un référentiel peut avoir deux branches master et dev. Si dev a été créée à partir de master et contient des commits qui ne sont pas dans master, mais que master n'a pas de commits qui ne sont pas dans dev, les deux branches existeront sur la même ligne de temps. Effectuer une fusion depuis dev vers maître entraînera une fusion rapide (fast forward merge). C’est-à-dire que Git déplacera simplement le pointeur qui représente la tête du maître vers le haut de la ligne au même point que dev. Le résultat final est que les deux branches pointent maintenant vers le même commit.
Cette ascendance permet également d'utiliser une grande variété de stratégies de ramification. Tandis que la création de branches de branches dans Subversion est généralement mal vue en raison des complexités potentielles liées à la fusion, il s'agit d'une pratique courante à Git. Avoir une véritable ascendance stockée avec chaque commit signifie que Git sait exactement où se trouve une branche par rapport à d'autres branches et ce qu'il faut faire lors de la fusion. Cependant, cela ne signifie pas que toutes les fusions sont simples dans Git. Un ensemble complexe de branches peut conduire à des situations de fusion complexes, nécessitant l'intervention de l'utilisateur, voire même d’un utilisateur très bien formé à Git. Comme je le disais dans l’introduction de la partie 1 je suis converti à Git mais ce n’est pas pour autant que je trouve tout merveilleux dans Git, certaines choses restent plus simples à comprendre dans Subversion. Dans des cas difficiles on peut arriver à des situations inextricables où l’on ne comprend rien et surtout dont on ne sait pas se sortir ! Seul quelqu’un très investi dans le fonctionnement de Git pourra après longues réflexions démêler l’écheveau et rétablir les choses. Git n’est pas magique ni miraculeux. Il a sa part d’ombre aussi et faire des bons backups réguliers, diversifiés et bien validés reste la base même du travail d’un pro en informatique !
De nom d'utilisateur à vrai nom et email
Lorsque les validations sont effectuées dans un référentiel Subversion, le nom d'utilisateur avec lequel vous vous êtes authentifié est stocké avec la validation. Cela permet aux autres de savoir qui a fait quoi et quand. Git fournit également des informations sur les auteurs des actes, mais utilise votre nom et votre adresse électronique au lieu d'un nom d'utilisateur. Comme Git est un système distribué et que rien ne garantit que les deux systèmes disposeront des mêmes mécanismes d'authentification, il n'existe aucun moyen de garantir qu'un nom d'utilisateur est disponible via l'authentification. Au lieu de cela, Git stocke votre nom et votre email dans sa configuration, qui peut être définie avec les commandes suivantes :
-
git config --global user.name “votre nom”
- git config --global user.email votre_email@example.com
Ces commandes stockeront votre nom et votre adresse électronique dans la configuration globale de Git, ce qui signifie que votre nom et votre adresse électronique seront les valeurs par défaut pour tous les référentiels avec lesquels vous travaillez.
Notez que certains logiciels et services d’hébergement Git enverront des messages d’avertissement ou d’erreur si votre nom et votre adresse électronique ne sont pas configurés. Par conséquent, vous devez configurer ces éléments immédiatement après avoir installé Git.
Conclusion de la partie 2
Nous en avons terminé avec les grandes différences de point de vue entre Subversion et Git. A ce stade vous devez comprendre pourquoi j’ai insisté sur le fait que passer à Git depuis Subversion implique un effort non pas d’apprentissage de commandes de façon mécanique en remplacement de celles qu’on utilise sous Subversion mais bien une effort important intellectuel pour comprendre le changement de paradigme entre ces deux façons de gérer du code source.
La partie 3 nous amènera tout naturellement à voir comment on utilise Git…
Pour ne rien rater…
Stay Tuned !