Git, ou l'écriture à N cerveaux - a podcast by Sylvain Abélard

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 pratiquequi ne va jamais cesser d’être utile. En plus, un code bien
versionné c’est le droit de faire des erreurs et revenir enarriè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 annexessans vraiment me dire pourquoi ils sont là, si on peut
s’en passer au début, ou si on peut apprendre juste quelquesparties 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 troplong 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 dedonner 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 à salangue 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 parci, 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 lelogiciel avance : une urgence, un patch de sécurité, et on doit soit
reprendre la version d’avant votre chantier, soit mettre en prodquelque 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 à lafin 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 aviezbesoin 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 excellenteconception 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 Grimmdans 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 modificationsde 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, à conditiond’ê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 brouillonsou 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 modificationssuccessives : 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 voulezvraiment 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 nouvelleversion 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 dedé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 venezde baser un système qui se centralise sur GitHub, et
en cas de problème chez eux, votre projet est affecté aussi.

Further episodes of Zen M-4 : Zen Metaphor

Further podcasts by Sylvain Abélard

Website of Sylvain Abélard