Git et GitLab dans la vraie vie

Ludwine Probst : Je suis aujourd'hui avec Anne Nicolas, co-fondatrice d'Hupstream et passionnée par les logiciels libres. Si je vous dis git commit, git push, git revert, vous l'aurez compris, je parle de Git. Dans cet épisode, nous allons parler de Git, mais aussi de GitLab. Anne, qui est formatrice sur ces deux technos, nous partage son expérience pour bien les utiliser sur vos projets et avec votre équipe. Bonjour Anne.

Anne Nicolas : Bonjour.

Ludwine Probst : Est-ce que tu peux te présenter rapidement ?

Anne Nicolas : Ça fait plus de 15 ans que je travaille dans l'Open Source. Je suis passée pas loin de 8 ans chez Mandriva, éditeur de distribution Linux. Comme j'ai beaucoup évolué dans ce milieu, j'ai vu Git arriver vers les années 2007-2008. C'est assez naturellement devenu un outil à part entière dans notre boîte à outils Open Source. Du coup, quand j'ai su que Human Coders cherchait des formateurs sur Git, je me suis dit que c'était une bonne occasion d'aller plus loin sur cet outil, de transmettre ce que j'avais appris au sein des projets et d'en faire profiter les autres, sachant que la formation est aussi un peu mon dada.

Ludwine Probst : Avec Git, je voulais te demander si tu pouvais rappeler ce que c'est et ce que ça permet de faire.

Anne Nicolas : Git, l'outil en lui-même, est un outil de gestion de version pour le code. Son objectif est de gérer un historique qui puisse être réutilisable par tous, de permettre le travail collaboratif sans se marcher sur les pieds, et d'avoir un outil efficace pour gérer toutes les situations possibles quand on a besoin de revenir en arrière sur son code.

Ludwine Probst : Tu me disais que Git peut être un petit peu traître parce qu'il semble simple. C'était mon cas quand j'étais développeuse : j'utilisais tout le temps les mêmes commandes, j'avais appris un peu bêtement git push, git checkout, etc. Finalement, dès qu'il y avait des choses un peu plus complexes à faire, j'avoue que je ne savais pas trop comment l'outil fonctionnait. C'est quelque chose que tu rencontres souvent ?

Anne Nicolas : C'est très récurrent. Ça fait quatre ans qu'on travaille avec Human Coders et je dirais que 98 % des gens que je vois passer en formation utilisent Git depuis un, deux ou trois ans avec une série de commandes quotidiennes. Au final, ils n'utilisent peut-être qu'un pour cent de ce que fait l'outil. Sans parler de ceux qui viennent d'autres gestionnaires de version comme Subversion et qui ont tendance à utiliser Git comme Subversion. Or, on a deux logiques qui sont presque antagonistes. En formation, je vois souvent des gens qui me disent qu'ils sont bloqués dès qu'il y a un problème, qu'ils ne savent pas pourquoi l'outil réagit de telle ou telle manière, ou pourquoi ils ont l'impression d'avoir perdu du code. C'est souvent parce que les fondamentaux de l'outil ne sont pas sus.

Ludwine Probst : Tu as des petits exemples de choses qu'on fait mal ou qu'on n'exploite pas avec Git ?

Anne Nicolas : Ça reviendrait à passer toutes les bonnes pratiques qu'on voit pendant les formations : de la bonne utilisation des messages de commit à la construction d'un historique lisible, réutilisable, qu'on peut reverter facilement. C'est quelque chose qu'on ne peut pas avoir si on ne sait pas comment fonctionne fondamentalement l'outil et si on n'a pas passé en revue un certain nombre de bonnes pratiques essentielles.

Ludwine Probst : Il y a GitLab qui existe maintenant. D'où est-ce que c'est né ? Est-ce que c'est un outil qui a été créé pour répondre à un besoin ou à quelque chose qui manquait dans Git ?

Anne Nicolas : GitLab date de 2011, ce qui est relativement récent puisque Git a été créé en 2005. GitLab est un outil qui a été développé suite à l'apparition de GitHub en 2008. Ces plateformes viennent se superposer sur Git. La base de toutes ces plateformes, c'est Git, l'outil qu'on utilise tous les jours. On a rajouté par-dessus une interface web avec un certain nombre d'outils indispensables dans le cadre du développement : le bug tracker, le wiki pour documenter, les outils de code review. L'avantage de ces plateformes, c'est qu'elles sont directement intégrées avec Git. On a des facilités dans toute la gestion de la chaîne de développement et de déploiement, car GitLab fait aussi maintenant du déploiement continu. Avant, dans les entreprises, on avait une brique Git, un outil de gestion de bugs comme Bugzilla, un wiki comme MediaWiki, et il fallait créer les passerelles entre tous ces outils pour les faire communiquer. Par exemple, avoir la possibilité de mettre un mot-clé dans un message de commit qui, quand on pousse le commit sur le serveur, va automatiquement alimenter une entrée dans le bug tracker. Toutes ces interactions sont devenues presque indispensables et sont fournies par GitLab, qui est en full Open Source, ou GitHub qui ne l'est pas mais qui est extrêmement populaire.

Ludwine Probst : J'ai vu GitLab CI qui existe aussi. C'est pour faire de l'intégration continue ? C'est une brique qui va s'ajouter à GitLab ?

Anne Nicolas : Ça permet de faire de l'intégration continue et du déploiement continu. C'est une brique qui a longtemps été développée en parallèle de GitLab et qui est aujourd'hui complètement intégrée. Quand on installe GitLab sur un serveur, on a aussi cet outil qui permet de déclencher des actions d'intégration ou de déploiement en fonction des commits qu'on va produire sur le serveur.

Ludwine Probst : Est-ce qu'il y a d'autres briques intéressantes à mentionner ?

Anne Nicolas : Avec ce type de plateforme, on a déjà beaucoup d'outils. L'idéal serait déjà d'arriver à maîtriser et organiser ça correctement. En plus d'avoir du mal à rentrer dans les abysses de Git, GitLab est aussi quelque chose d'extrêmement touffu. On fait du conseil en entreprise sur GitLab et souvent, on voit des utilisations basiques : l'interface web sert à gérer les comptes utilisateurs, éventuellement le bug tracker, mais ça ne va jamais très loin.

Ludwine Probst : D'où est-ce que ça vient selon toi ? On voit que comme pour Git, les gens ont du mal à vraiment utiliser toutes les fonctionnalités.

Anne Nicolas : C'est assez général. Ce sont considérés comme des outils. Pour les utiliser, on prend le mode d'emploi et on fait en sorte que ça tourne, sans pour autant chercher toutes les possibilités. Souvent, on a des usages au sein de l'entreprise et on essaie de tordre l'outil pour qu'il corresponde exactement aux usages qu'on avait précédemment. Or, Git et GitLab font qu'il va falloir revoir un certain nombre d'usages et de façons de travailler. C'est ça qui est difficile à mettre en adéquation. Quand on fait de l'accompagnement, on se rend compte que ça permet effectivement de remettre à plat les façons de travailler, les bonnes pratiques et les workflows. Si on ne le fait pas, on arrive à des situations un peu pénibles où on subit l'outil. On se retrouve avec des équipes de développeurs complètement démotivés qui pensent que l'outil ne fonctionne pas ou ne fait pas ce qu'on leur demande.

Ludwine Probst : Est-ce que tu as des conseils ou un message à faire passer aux potentiels utilisateurs de ces outils ?

Anne Nicolas : La migration vers Git, côté serveur, est ce qu'il y a de plus simple car c'est extrêmement bien documenté. La grosse difficulté se situe au niveau des utilisateurs. La formation est extrêmement importante. Si les utilisateurs s'approprient l'outil, c'est presque gagné. Mais la formation ne suffit pas, il faut mettre en place à côté un document qui explique la manière dont on va utiliser l'outil. Git a la particularité d'être extrêmement permissif. On peut faire plein de choses avec, même des choses absolument dégueulasses. L'idée est d'expliquer le workflow de travail, les bonnes pratiques qu'on entend appliquer, comment on écrit les messages de commit, comment on travaille dans les branches, comment on les nomme... Tout ça doit être documenté. Quand c'est documenté, ça borde l'utilisation de l'outil et ça évite que ça parte en n'importe quoi. De plus en plus de gens sont formés sur Git aujourd'hui, ils ont leurs propres habitudes qui ne sont pas forcément celles du projet qu'ils vont intégrer. Si on ne borde pas, ça peut vite devenir la catastrophe.

Ludwine Probst : Sur ce fameux rebase, quel est l'impact ? Comment privilégies-tu l'un ou l'autre ?

Anne Nicolas : Le rebase est probablement l'outil le plus controversé sur Git. Si on cherche de l'info sur le net, on va trouver tout et son contraire. Il y a des gens qui vont dire que c'est génial et des projets qui proscrivent totalement l'utilisation du rebase. Le rebase est un outil de réécriture d'historique. On modifie un historique existant. Il y a des précautions à prendre : on dit souvent qu'il ne faut pas modifier un historique qui a déjà été partagé sur le serveur parce que ça fout la pagaille. Deuxième chose importante : ça modifie l'historique de manière complètement transparente. On va faire un certain nombre d'actions sur l'historique sans que ça se voie jamais. Il y a une perte d'information à ce niveau-là. La question est de savoir si j'ai besoin de cette information ou pas. Certains diront qu'il faut que ce soit complètement transparent, qu'on veut tout voir, donc le rebase s'applique difficilement. D'autres diront que dans certains cas, l'information n'est peut-être pas essentielle et qu'on peut se permettre de l'occulter. C'est ce genre de questions qu'il faut se poser rapidement, pas au moment où c'est la pagaille.

Ludwine Probst : Pour résumer, quand vous utilisez Git, posez les bonnes pratiques ensemble, décidez des limites, de comment faire vos messages dans les commits, de faire du rebase ou pas. Posez vraiment un cadre.

Anne Nicolas : Tout à fait. Ça dépend de la culture d'entreprise. Il y a des sociétés où ça va venir d'en haut et s'appliquer sur l'équipe. J'en ai vu d'autres où on l'a fait ensemble, au sein de l'équipe, avec tout le monde autour de la table. C'est la meilleure des choses à faire car ça permet à tout le monde de s'approprier les décisions qui ont été prises et de les comprendre, même si on n'est pas tout à fait d'accord sur tout.

Ludwine Probst : Sur le rebase, je me souviens que suivant à qui je demandais dans l'équipe, tout le monde n'avait pas la même opinion. C'était toujours le débat.

Anne Nicolas : J'ai laissé sur un des slides de la formation un petit lien vers un mail qui avait été envoyé par Linus Torvalds, le créateur de Git. Il n'a pas pour habitude d'être très diplomate, il a parfois un langage un peu fleuri, et il explique tout le bien qu'il pense du rebase quand c'est mal utilisé. On a un exemple très concret qui date de 2008. C'est un problème récurrent qui se pose régulièrement. Si on ne clarifie pas ce type de problématique, ça peut être embêtant pour la bonne tenue du projet.

Ludwine Probst : Est-ce que GitLab a été créé par la même équipe ?

Anne Nicolas : Non, ce sont deux projets différents. Il y a une société derrière GitLab. Aujourd'hui, c'est un mode mixte : ils proposent en libre accès la plupart de ce qui fait GitLab, et les toutes dernières fonctionnalités sont proposées en exclusivité à ceux qui achètent une licence entreprise. Globalement, pour un usage courant, la version communautaire est largement suffisante. Ce sont des gens qui sont a priori extrêmement expérimentés sur Git, car sinon ce serait très compliqué de monter ce type d'outil.

Ludwine Probst : Est-ce que dans GitLab tu recommandes aussi d'avoir un cadre comme pour Git ?

Anne Nicolas : Oui, car le cadre qu'on pose sur Git va s'appliquer sur GitLab. Ensuite, on va rajouter la façon dont on voudrait proposer de remplir un bug tracker, comment on gère les merge requests, les workflows de merge requests. Tout ça doit être formalisé et les gens doivent être formés pour qu'on aille exactement là où on veut aller. Ce sont des problématiques supplémentaires par rapport au cadre Git.

Ludwine Probst : Sur les limites, est-ce qu'il y a des choses que tu n'aimes pas ou qui sont ennuyeuses dans Git ou GitLab ?

Anne Nicolas : GitLab, je connais un petit peu moins bien car je me suis focalisée sur GitLab. Pour le moment, non, il y a moyen d'adapter l'outil à ce qu'on veut en faire. Je ne suis pas arrivée à un point où je me dis que tel truc est vraiment pénible sur GitLab.

Ludwine Probst : J'ai lu plein de commentaires qui disaient que l'interface n'était pas top.

Anne Nicolas : Il faudrait savoir ce qu'ils entendent par "pas top". Après, je ne l'ai pas utilisé récemment donc je ne sais pas.

Ludwine Probst : Est-ce que GitLab est fait pour n'importe quel projet ou plutôt pour certains types ?

Anne Nicolas : Ça peut s'adapter à n'importe quel projet. Je l'ai vu utilisé sur des projets de développement pur, sur de l'administration système pour faire du déploiement continu, ou pour des projets de documentation quand le format s'y prête. C'est comme n'importe quel outil : il faut bien le connaître et l'adapter à ses besoins.

Ludwine Probst : Autre chose que tu aimerais partager ou un message à faire passer ?

Anne Nicolas : Je vais me répéter, mais il y a un vrai intérêt à se former. Git n'est pas facile. Bien connaître comment l'outil fonctionne, ce qui se passe "dans le moteur", permet de mieux comprendre le fonctionnement, de devenir autonome et d'aller plus loin pour faire des choses beaucoup plus efficaces. Il faut faire cet effort initial. Pour l'entreprise, c'est un coût de formation, mais on a souvent tendance à se dire "je vais utiliser des outils Open Source, ça va me coûter moins cher, je vais faire tout tout seul". Je pense sincèrement que là, c'est compliqué.

Ludwine Probst : Est-ce que tu as des exemples de risques à mal utiliser Git ? Quels sont les plus gros fails ?

Anne Nicolas : On est intervenus une fois dans une boîte qui avait perdu des commits. Ils pensaient qu'ils avaient tout un pan de développement qui avait disparu de leur historique de commits. Ça représentait plusieurs jours de développement. Ça se récupère, ça met un peu de temps, mais quand on est formé sur les tenants et les aboutissants, les conséquences de ce qu'on fait, on limite ce type de risque.

Ludwine Probst : Merci encore Anne pour toutes ces recommandations. À vous de jouer maintenant en définissant le cadre qui vous correspond ! J'espère que cet épisode vous a plu, n'hésitez pas à venir en discuter sur notre blog ou à nous suivre sur les réseaux sociaux. Je vous dis à très bientôt dans un nouvel épisode.