Bonjour, bienvenue dans l’épisode 12 sur Git.

Beaucoup de cours pour apprendre à coder se basent sur Git, et c’est très bien de viser tout de suite une bonne pratique qui ne va jamais cesser d’être utile. En plus, un code bien versionné c’est le droit de faire des erreurs et revenir en arrière, ce qui est parfait pour se rassurer quand on tente des choses nouvelles.

Mais cela bloque aussi les débutants : je voulais “juste” apprendre à coder, et voilà qu’on me gave d’outils annexes sans vraiment me dire pourquoi ils sont là, si on peut s’en passer au début, ou si on peut apprendre juste quelques parties et se lancer, ou qu’on doit tout savoir dès le début.

Du coup le but ici n’est pas de vous faire une liste des commandes (j’ai essayé avec l’épisode sur les itérateurs, c’est beaucoup trop long et pas forcément adapté en podcast, et en plus il y a déjà pléthore de sites et docs très bien faits) mais encore une fois de donner une vue d’ensemble pour dédramatiser le sujet.

La tradition orale

J’aimerais rapprocher l’écriture de code (du texte à la base), avec quelque chose que l’humanité fait depuis très longtemps : raconter des histoires.

Dans toutes les cultures, mythes, légendes, contes se transmettent par tradition orale : les griots, les druides, les aedes grecs… et un jour tout cela se cristallise dans un ouvrage : l’épopée de Gilgamesh ou l’Iliade et l’Odyssée, etc.

Comme dans le logiciel ou le business, l’écriture dans une version “canonique” n’empêche pas les reprises, redécouvertes ou réinventions : Molière a repris énormément d’idées de ses fables chez Esope, pourtant il a écrit quelque chose d’original en l’adaptant à sa langue et à son époque.

Pourquoi versionner ?

On souhaite avoir plusieurs versions d’un logiciel qu’on écrit : soit parce qu’on travaille à plusieurs, soit pour faire une expérience par ci, une tentative par là, sans que cela ne bloque tout le monde.

Vous avez tenté quelque chose de trop courageux toute la journée de mardi ? Rien ne marche le soir ? Pas de souci : on revient à la version de lundi.

Quand on commence un long chantier sur son code, on ne veut pas le mettre en prod tant qu’il n’est pas fini, pourtant il faut bien que le logiciel avance : une urgence, un patch de sécurité, et on doit soit reprendre la version d’avant votre chantier, soit mettre en prod quelque chose qui n’est pas maîtrisé.

Une façon simple de faire ça était de tout copier-coller dans des dossiers, avec des noms plus ou moins explicites (v1, v2, backup, test…) mais plus on va mener de chantiers en parallèle plus ça va être difficile, déjà de tracer, mais ensuite de remettre ensemble à la fin quand le résultat est satisfaisant et “mérite” de rentrer dans le produit final.

Les conflits

Bien entendu, ça arrive tout le temps. Parfois, pour avancer, on doit se baser sur une hypothèse différente : pour le métier, une découverte qui n’était pas dans le plan de base, une contrainte légale ou une opportunité business ; pour les développeurs, des contraintes ou opportunités techniques.

Votre code et votre base de données peuvent avoir des changements majeurs qui mettent une partie du système KO. Quand ça arrive, votre code est en conflit avec celui du voisin.

Par exemple, dans l’histoire du barde voisin, le personnage principal meurt, c’est bien plus dramatique, mais vous en aviez besoin dans la scène finale que vous aviez enjolivée : l’un des deux aspects va devoir changer, quitte à faire deux ouvrages.

Quand ça n’arrive pas ou très rarement… soit votre projet ne change plus (pas toujours bon signe) soit vous aviez une excellente conception ou architecture logicielle (souvent le genre de choses dont on se rend compte avec beaucoup d’expérience, ou a posteriori).

Gestion de version, distribuée

Typiquement les versions des contes de Grimm finissent mal et les Disney finissent bien : je ne dis pas que l’un ou l’autre a raison, ils ont chacun leur public, leur époque, leur succès, et sont tous les deux dépositaires d’une version qui est stable et se suffit à elle-même.

Chez les développeurs, ce serait un fork du logiciel, et chacun vivra sa vie complètement séparée de l’autre. On ne remet plus trop de Grimm dans les Disney, l’inverse à la rigueur ?

Ça peut être un changement de version majeure de la 1.0 à la 2.0, ou deux branches de la même histoire qui coexistent.

Mais des scénaristes qui travaillent en parallèle ? Tout simplement sont deux dépôts du même code, qui ont vocation à fusionner un jour en reprenant le meilleur de chaque. Régulièrement, ils s’envoient ou ils vont chercher les modifications de l’autre.

Git est prévu pour ça, pour s’échanger les différences pour que chacun puisse profiter des améliorations de l’autre, à condition d’être prêt à résoudre les conflits.

Dépôt, branche, versions, table de travail

Du coup, Git propose énormément de commandes en fonction des subtilités choisies : cloner, envoyer, récupérer les dépôts ; expérimenter et naviguer entre plusieurs branches des possibles ; voir l’état de votre table de travail, jeter les brouillons ou intégrer les nouveaux travaux à telle ou telle branche ; fusionner les modifications.

Enfin, parfois, vous voulez présenter non seulement votre travail à quelqu’un, mais qu’il ne voie pas les annotations et modifications successives : on peut alors réécrire l’histoire des commits.

Là encore, ça n’est pas une opération quotidienne ou anodine : maîtrisez d’abord la base et vous saurez par la suite si vous voulez vraiment le faire, et armé de la pratique git que vous aurez eu entretemps, la méthode vous semblera plus claire.

Le distribué centralisé

C’est compliqué d’imaginer que chacun a sa version. De toutes façon, un seul logiciel finira en production dans votre entreprise. Souvent, on va se dire qu’un des dépôts a autorité sur les autres, disons celui de l’entreprise ou du projet et pas celui des contributeurs. Au lieu de vous synchroniser avec chacun de vos collègues, vous le ferez via celui-ci.

Git est si populaire que de nombreux outils de développement se basent dessus : l’intégration continue par exemple, permet de dire “quand une nouvelle version est envoyée à tel endroit, lance des tests, et s’ils réussissent, déploie le tout en production”. Confort maximum, gain de temps : bel exemple d’automatisation.

Il existe aussi de nombreuses plateformes, publiques ou privées. GitHub étant devenu de fait un hébergeur majeur de projets Open Source, il y a de fortes chances que toutes les briques dont votre projet a besoin pour fonctionner soient sur GitHub. Si vous avez un outil de gestion de dépendances (npm pour Node, gem pour Ruby par exemple), il y a de fortes chances pour qu’il aille tout chercher sur GitHub.

Du coup, bien que Git soit conçu pour être un système distribué, vous venez de baser un système qui se centralise sur GitHub, et en cas de problème chez eux, votre projet est affecté aussi.