Chapitre 4.5.3
GitHub et GitLab

Git est un outil qui fait très bien son travail de gestion de versions. Mais il ne propose rien pour organiser la collaboration au-delà de l'échange de commits. Comment demander à un collègue de relire ton code avant qu'il soit intégré ? Comment suivre les bugs et les demandes de fonctionnalités ?

C'est le rôle des plateformes de développement : des applications web construites autour de Git qui ajoutent des couches de collaboration, d'automatisation et de gestion de projet. Les deux leaders sont GitHub et GitLab.

Deux plateformes

En 2008, trois ans après la création de Git, GitHub est lancé. L'idée : offrir un hébergement de projets Git avec une interface web conviviale, gratuite pour les projets publics. Le timing est parfait. Git commence à s'imposer, mais son interface en ligne de commande rebute beaucoup de développeurs. GitHub le rend accessible et y ajoute une dimension sociale : profils de développeurs, système de favoris, possibilité de copier un projet public pour y contribuer.

GitHub devient rapidement le lieu de rassemblement de la communauté open source mondiale. Le noyau Linux, React, Python, Ruby on Rails... les plus grands projets du monde s'y installent. En 2018, Microsoft rachète GitHub pour 7,5 milliards de dollars.

GitLab naît en 2011. Sa particularité : c'est un logiciel open source que n'importe quelle entreprise peut installer sur ses propres serveurs. Pour les entreprises soucieuses de garder leur code en interne (banques, défense, santé...), c'est un argument décisif. GitLab s'est aussi distingué en intégrant très tôt des outils d'automatisation directement dans la plateforme, là où GitHub a longtemps reposé sur des services tiers.

Aujourd'hui, les deux plateformes offrent des fonctionnalités très similaires. Le choix dépend souvent de l'écosystème existant, des habitudes de l'équipe et des contraintes de sécurité.

La pull request

Une pull request (sur GitHub) ou merge request (sur GitLab), c'est une demande de fusion. Un développeur dit : "J'ai fini mon travail sur ma branche, j'aimerais qu'il soit intégré dans la branche principale. Pouvez-vous vérifier ?"

La plateforme affiche alors toutes les différences entre les deux branches. Les collègues peuvent commenter n'importe quelle ligne, poser des questions, suggérer des modifications. L'auteur ajuste son code, repousse des modifications, et la pull request se met à jour automatiquement.

Quand tout le monde est satisfait, la pull request est approuvée et fusionnée.

Les issues : suivre le travail

GitHub et GitLab proposent aussi des outils de gestion de projet. Une issue (ticket), c'est une unité de travail : un bug à corriger, une fonctionnalité à développer, une amélioration technique à apporter.

Les issues peuvent être assignées à quelqu'un, étiquetées (bug, urgent, fonctionnalité...) et liées à des pull requests. Quand un développeur ouvre une pull request qui résout une issue, il la référence : la plateforme ferme automatiquement l'issue quand la PR est fusionnée.

Pour les équipes produit et marketing, les issues sont souvent le premier point de contact avec le travail des développeurs. C'est là qu'on dépose les demandes, qu'on suit l'avancement et qu'on participe aux discussions.

L'automatisation

Les plateformes permettent aussi d'automatiser des vérifications lors des modifications de code. À chaque pull request, un pipeline peut se déclencher automatiquement pour compiler le code, lancer les tests, vérifier les conventions de l'équipe et détecter des failles de sécurité.

Si une étape échoue, la pull request est marquée en rouge et la fusion est bloquée. C'est ce qu'on appelle la CI/CD (intégration continue et déploiement continu), un sujet que nous approfondirons dans un chapitre dédié.

L'open source : construire ensemble

GitHub a joué un rôle majeur dans l'explosion du mouvement open source. En rendant trivial le fait de publier son code et d'y contribuer, la plateforme a transformé la façon dont les logiciels sont construits.

N'importe qui dans le monde peut copier un projet public, le modifier et proposer ses modifications au projet original via une pull request. Les mainteneurs relisent, discutent et décident d'accepter ou non.

Ce modèle a permis la création de logiciels utilisés par des milliards de personnes, développés par des communautés de milliers de contributeurs bénévoles. Linux, Android, WordPress, Firefox, VS Code, Python...