Depuis un moment Visual Studio gère parfaitement l’intégration de Git. Certains en sont fans depuis le premier jour, d’autres continuent avec Subversion. Mais la pression environnementale dans notre métier est telle qu’il faut passer à Git… Comment le faire le plus facilement ?
Passer de Subversion à Git
Le problème, si c’en est un ?
L’idée d’aborder le passage de Subversion à Git m’est venu de plusieurs sources. Ma propre expérience pour commencer, à titre personnel pour les dossiers traités en interne pour E-Naxos et à titre de conseil pour les client de E-Naxos. En ce qui me concerne J’ai toujours bien aimé Subversion, c’est clair, c’est net, facile. Obligé par certaines missions à travailler avec Git je dois dire qu’au départ cela a été difficile. Tout simplement car je n’arriverai pas à comprendre le nouveau paradigme véhiculé par Git. A vouloir sans cesse faire des comparaisons entre mes habitudes personnelles sur mon propre réseau, mon propre serveur etc, je voyais bien l’intérêt de Git pour d’énormes projets Open Source partagés par des milliers de personnes, mais je ne comprenais pas les avantages pour une personne seule ou même une équipe de développement en entreprise. Il m’a fallu accepter de revoir ma position, de m’ouvrir à l’esprit de Git pour sentir la nécessité d’abandonner Subversion… Mais vous dire que cela m’est venu d’un coup serait mentir. Le premier dossier où j’ai été confronté à Git par obligation j’ai passé mon temps à maugréer sur cette “saleté” de Git qui ne faisait rien comme je le voulais !
Puis, il faut l’admettre, sans embrasser avec joie l’ensemble du fonctionnement de Git qui reste un peu magique par endroit, j’ai fini par adopter la façon de travailler de Git et à savoir en tirer partie.
S’il lit cet article c’est certainement mon ex collègue et ami Patrice Ongla qui sera surpris de me voir ainsi en chantre de la défense de Git, lui a qui fait partie de ceux qui ont eu à supporter mes grognements contre ce même Git ! Et si je le cite ici c’est aussi pour lui rendre l’hommage qu’il mérite dans ses efforts pédagogiques pour me faire quitter mes anciens paradigmes.
La transition
Puis est venu un jour un autre gros dossier où j’ai du revenir à Subversion… Et là je me suis surpris à grommeler contre Subversion comme je le faisais avant pour Git… Je venais de comprendre que j’avais terminé ma conversion…
Vous me connaissez, je vulgarise et j’évangélise à tour de bras depuis des lustres. Qu’une idée me vienne et j’ai envie d’en faire profiter le plus de gens possible !
Et là je me suis demandé, qu’est-ce qui m’a fait perdre du temps dans le passage de Subversion à Git ? Qu’est-ce qui m’a gêné ? Je ne suis pas conservateur, je ne suis pas matérialiste, si je reconnais les quelques graves errances de notre époque je ne suis du genre à penser que CEMA (C’Etait Mieux Avant). Donc d’où me venait ma résistance au changement sur ce sujet précis ?
Si je trouvais la clé je pourrai en faire profiter les autres… Et j’apprendrais quelque chose sur moi au passage ce qui est toujours utile.
Transmettre
C’est en retombant sur un vieux numéro de Code Magazine de 2011 que j’ai eu l’idée de transmettre à mon tour ce que j’avais appris de Git. L’article présentait ce passage comme un changement de paradigme plus que comme un changement de technologie. Et c’était évidemment le bon angle d’attaque. Je devais passer le flambeau, j’étais mûr…
La connaissance technique est universelle et elle n’appartient à personne en particulier. Sinon bye-bye les 200 blogs qui sortent sur le même sujet lorsque Microsoft ou d’autres sortent une nouveauté… Cette diversité n’est pas forcément synonyme de qualité, certains comme les mauvais journalistes d’aujourd’hui ne font que répéter les dépêches AFP et n’apportent rien de plus que le communiqué original. D’autres y ajoutent leur grain de sel. Et c’est bien.Tout en parlant de la même chose ils en parlent de façon différente. Utilisant d’autres images, d’autres termes. Et chaque lecteur sera sensible à telle ou telle expression ou comparaison et pas à une autre. Il y en a ainsi pour tout le monde. Le savoir technique et scientifique se partage, se copiant par force car on ne peut changer le fond qui est le même, mais se vulgarisant sous des plumes différentes il atteint et touche un plus grand nombre de personnes. Et c’est la force de l’humanité, stocker et partager le savoir, cela nous a fait sortir des cavernes… (où nos lointains ancêtres n’habitaient pas du tout, c’est un cliché idiot. Essayez de faire un feu dans une grotte sans étouffer ni mourir d’intoxication au monoxyde de carbone et vous comprendrez la bêtise de ce vieux cliché de l’homme préhistorique devant un bon feu dans sa caverne !).
Passer de Subversion à Git n’est ainsi pas une question d’apprentissage de nouvelles commandes mais bien plus celle de capter le changement de point de vue sur la fonction elle-même, identique dans les deux logiciels, gérer du code source et ses évolutions.
Passer de Subversion à Git
Il y a quelques similitudes entre Subversion et Git. Ce sont deux systèmes de contrôle de source qui fonctionnent sur presque toutes les plateformes de développement modernes. Ils sont à la fois populaires et open source, devenant aussi des points d’intégration pour d’autres outils de développement. Ils prennent tous les deux en charge la création de branches, la fusion et l'utilisation de fichiers sans les verrouiller. Il existe encore d'autres similitudes. Comprendre en quoi ces systèmes sont similaires peut être important pour ceux qui ont déjà utilisé Subversion et qui veulent apprendre Git. Cependant, la compréhension des similarités ne sera pas suffisante pour apprendre Git. Il est également nécessaire de comprendre les différences et d’examiner certaines des fonctionnalités fournies par Git pour lesquelles Subversion n’a pas d’équivalent !
Une suite de changements de paradigmes
Bien qu'un certain nombre d'idées se retrouvent de Subversion à Git, d'autres idées dans Git n'auront pas d'équivalent. Avoir une compréhension de base des différences entre Subversion et Git vous permettra de mieux comprendre Git et pourquoi certaines actions et commandes sont nécessaires.
Avant tout il faut comprendre qu’il ne s’agit pas juste d’apprendre de nouvelles commandes, mais bien d’intégrer les différents changements de paradigmes.
Alors regardons ensemble tous ces changements de point de vue, c’est leur somme qui fait l’avantage de Git et c’est leur nombre qui rend le passage abrupt de l’un à l’autre si difficile, non pas à cause du mode de fonctionnement, mais bien à cause de la difficulté bien plus grande que nous avons de changer de point de vue sur une chose que d’apprendre de nouvelles commandes d’un logiciel.
Passer de Subversion à Git est donc plus un exercice philosophique de remise en question de sa façon de voir le monde qu’un simple problème de connaissances techniques nouvelles à acquérir…
De centralisé à distribué
Subversion, parmi de nombreux autres systèmes de contrôle des sources populaires tels que CVS et Team Foundation Server, résout beaucoup de problèmes propres à ces systèmes en utilisant un modèle de référentiel centralisé. Les utilisateurs qui souhaitent travailler avec ce référentiel feront une copie de ce dont ils ont besoin sur leur ordinateur local depuis un serveur, ils apporteront les modifications nécessaires, puis les valideront directement dans le référentiel du serveur. Ce modèle assure la collaboration en permettant à tout le monde de travailler sur le même serveur, son travail étant visible par tous les autres lors de la validation. La figure ci-dessous illustre ce modèle classique de contrôle de source avec un serveur centralisé et de nombreux utilisateurs travaillant dans le référentiel.
Contrairement aux systèmes de type Subversion centralisés, les systèmes distribués ne nécessitent pas de serveur central, bien que l'on puisse en utiliser un. Les utilisateurs travaillent à la place sur un référentiel local, comme illustré à la figure suivante, et non sur un serveur en particulier. La plupart des actions entreprises sur le référentiel sont effectuées localement, notamment le check out des fichiers sur lesquels travailler, les modifications et la validation de ces fichiers (commit). Ce n'est que lorsque l'utilisateur est prêt à partager son travail qu'il doit penser aux référentiels qui ne sont pas sur son ordinateur. À ce stade, toutefois, l'utilisateur n'a pas à transmettre ses modifications à un serveur central. Il peut transmettre directement les modifications aux autres utilisateurs ou laisser les autres venir piocher eux-mêmes les modifications sur sa machine.
Bien entendu aujourd’hui on voit surtout Git utilisé avec un serveur central, ce qui rend plus difficile la compréhension du changement de paradigme car on ne voit pas ce changement. Toutefois l’essence de Git est dans cette organisation décentralisée, le comprendre c’est mieux entrevoir pourquoi il travaille d’une façon différente de celle de Subversion.
De client-serveur à peer-to-peer
En plus de travailler avec votre référentiel local, Git offre la possibilité de se connecter à n’importe quel référentiel de Git distant, comme illustré à la figure précédente. Dans une configuration d'homologue à homologue (peer-to-peer) telle que celle-ci, les validations sont transférées directement entre les utilisateurs, plutôt que via un serveur centralisé. Git prend toujours en charge l'utilisation d'un serveur central partagé, mais celui-ci n'est pas strictement nécessaire. Git a été pensé pour les développements open-source où des centaines voire des milliers de développeurs interviennent. On n’y trouve donc aucun moyen de locker un fichier (cela serait vite la paralysie !) mais en revanche on trouve se mode de fonctionnement totalement décentralisé et insensible à une autorité centrale. En entreprise toutefois on rencontre plus souvent un serveur central car il n’est pas raisonnable dans un tel environnement de laisser le code source se « diluer » sur le net ou entre les machines des employés. Même des systèmes collaboratifs comme GitHub fonctionnent sur ce mode d’un serveur centralisé. Le mode peer-to-peer est essentiel à comprendre pour ressentir l’esprit de Git mais ce n’est pas celui qu’on rencontre le plus souvent.
D'un référentiel Subversion aux Remotes Git
Lorsque vous effectuez un checkout à partir d'un référentiel Subversion, les informations sur le serveur sont stockées dans le système de fichiers local. Cela indique au client Subversion où se trouve le serveur, comment y accéder et l'état le plus récent du référentiel qui a été extrait vers l'ordinateur local. Un checkout Subversion peut pointer vers un et un seul référentiel, et tout le travail est effectué sur ce référentiel.
Avec Git, cependant, il est possible de configurer plusieurs connexions à plusieurs référentiels distants. Vous faites cela en utilisant des Remotes Git . Un Remote est un ensemble de détails de configuration qui indique à Git où se trouve le référentiel distant, comment y accéder et quel est l'état le plus récemment connu du référentiel distant. Git peut se connecter aux Remotes configurés à tout moment et il n’existe que quelques commandes spécialement conçues pour interagir avec des référentiels distants.
Du Trunk au Master
Les référentiels Subversion ont généralement des dossiers appelés branches, tags et trunk. Le Trunk représente l'emplacement principal du contenu traité dans le référentiel et est distinct des branches pouvant exister dans le référentiel. Bien que Subversion ne nécessite pas de structure de dossiers en branches, tags et trunk, c'est la façon la plus courante de travailler. La plupart des logiciels clients Subversion s’attendent à cela ou au moins recherche cette structure et savent comment l’utiliser.
Avec Git, l’équivalent de trunk est la branche principale.
Techniquement, il n'y a pas de distinction entre la branche master et toute autre branche du référentiel pour Git. Par convention, cependant, la plupart des référentiels Git ont une branche principale qui représente la version la plus récente et la plus stable du contenu du référentiel. Cependant, il n'est pas nécessaire qu'un référentiel Git ait une branche nommée master ; ceci est seulement une convention intégrée par défaut à Git.
De Checkout à Clone et Checkout
Un utilisateur de subversion va importer (via checkout) le trunk ou la branche avec laquelle il doit travailler. Cela amène une copie du trunk ou de la branche dans la structure de répertoires de travail de l'ordinateur local.
Un utilisateur Git peut effectuer un clone d'un référentiel distant pour créer un référentiel local, qui contiendra les mêmes commits et contenus que le repository centralisé (ou non). Lorsque vous effectuez un clone, la branche maître est tirée du dépôt distant vers le référentiel local, par défaut. Vous pouvez ramener d'autres branches en plus ou au lieu de la seule branche principale, si nécessaire. Le clone configure également un lien vers le référentiel distant, appelé git remote, avec un nom d'origine par défaut.
Une fois que le clone est créé, l'utilisateur utilise directement son référentiel local faisant en des checkouts sur la branche avec laquelle il souhaite travailler. Cependant, cela ne nécessite pas de connexion au référentiel distant. Le checkout a lieu dans la structure de répertoires de travail du référentiel cloné. Le serveur n'est pas appelé ni mis à jour !
Des branches basées sur le serveur aux branches locales
Une branche dans Subversion est définie sur le serveur. Pour travailler avec cette branche un développeur doit extraire cette branche ou «basculer» (switch) leur extraction actuelle vers cette branche. Une fois que le développeur a fini de travailler dans cette branche, il procède à un checkout ou à un autre « switch » vers une autre branche ou le trunk.
Une branche dans Git peut être définie dans le référentiel local d'un utilisateur.
Même lorsqu'une branche est disponible sur un référentiel distant, le développeur doit la ramener dans son référentiel local avant de pouvoir travailler dessus. Il doit toujours effectuer une commande de checkout pour basculer vers cette branche et travailler dessus. Cependant, cette extraction ne nécessite pas de connexion à un référentiel distant. Seuls le Fetch ou le Pull pour amener la branche dans votre référentiel local nécessite une connexion à une connexion distante.
Le développeur peut également créer des branches locales dans un référentiel Git sans avoir besoin d'une connexion distante, car une branche Git n'est pas automatiquement partagée avec un référentiel distant. Cela permet à un développeur de disposer de nombreuses branches locales qui lui sont utiles, sans qu'aucun autre développeur ne les connaisse ou ne les voie. Git permet à chacun d’avoir son « style », sa façon de travailler, sans « polluer » le repository central ni ses collègues.
Avec plusieurs branches disponibles dans un référentiel Git local, vous pouvez facilement oublier sur quelle branche vous travaillez... Heureusement, le logiciel client Git, y compris la ligne de commande Git, vous indiquera la branche sur laquelle vous travaillez. La commande git status donne le nom de la branche actuelle.
Il est également possible de configurer divers shells de ligne de commande pour afficher le nom de la branche actuelle. Certains shell donnent plus d’informations comme le nom de l'utilisateur connecté à Windows, le nom de l'ordinateur, le dossier actuel et la branche Git actuelle.
D'une hiérarchie de type dossier avec des validations à une chronologie des validations
En regardant une structure de référentiel Subversion, vous découvrirez une structure de dossier dans laquelle les branches, les tags et le trunk sont organisés. Les branches de subversion sont souvent organisées en sous-dossiers et hiérarchies pour aider l’équipe à les suivre. Par exemple, une équipe peut avoir un dossier « correctifs » qui contient des branches pour la correction des bogues. Ils peuvent également avoir un dossier de « développement » pour les branches se rapportant à de nouveaux développements ou fonctionnalités. Certaines équipes ont des dossiers de branche nommés d'après des développeurs individuels afin que le développeur puisse disposer de son propre ensemble de branches dont personne ne doit s'inquiéter.
Le (la) HEAD est un pointeur nommé sur un commit spécifique, représentant le commit actuel d'une branche donnée.
Dans Git, il n'y a pas de hiérarchie de dossiers. Au lieu de cela, Git maintient la connaissance de chaque branche via ce qu'on appelle des HEADs. Un HEAD est un pointeur nommé sur un commit spécifique, représentant le commit actuel d'une branche donnée. Lorsque vous effectuez une validation sur la branche principale, Git déplace le pointeur sur la nouvelle validation.
Une équipe peut toujours avoir des branches pour les corrections de bugs et les nouveaux efforts de développement, mais un référentiel sur la machine locale d'un développeur n'a besoin que de contenir les branches qui l'intéressent. Le développeur individuel n'a pas besoin de rapporter toutes les branches de tous les référentiels distants vers son référentiel local. S'il n'a pas besoin des branches de correction de bogues sur lesquelles travaille une autre personne, il ne les rapporte pas dans son référentiel. Cela élimine le besoin d'une hiérarchie de dossiers pour organiser les branches du référentiel.
Conclusion Partie 1
On va s'arrêter là pour aujourd'hui, il reste beaucoup à dire et faire trop long risque d'être contre-productif en vous noyant sous l'information.
Il m'est apparu plus judicieux de scinder l'article en deux ou trois parties.
Il y aura au moins une partie 2 alors pour ne rien louper, surtout...
Stay Tuned !