Git et GitHub sont des outils clés pour collaborer sur un projet. Pour Open Transport, ce sont également de vrais atouts pour intégrer de nouveaux collaborateurs car c’est un outil connu et maîtrisé par la plupart d’entre eux. Mais attention, cela ne garantit pas une collaboration efficace !
On nous aurait menti ?!
Mais non, rassurez-vous ! 
Il faut simplement garder en tête que, même si 2 personnes ont un outil en commun, cela ne garantit pas automatiquement une collaboration efficace.
Imaginez, par exemple, que vous recrutiez 2 menuisiers pour faire des travaux chez vous. Tous les deux sauront utiliser un marteau pour intervenir sur votre charpente. Imaginez maintenant que ces 2 menuisiers ne parlent pas la même langue et qu'ils n’arrivent pas à se comprendre l’un l’autre pour savoir qui utilise le marteau et à quel moment. Assurément la collaboration ne sera pas des plus efficaces ! 
Vous pourriez rencontrer exactement le même problème avec Git et GitHub. Vos collaborateurs maîtrisent l’outil, mais ils ont peut-être chacun leurs propres habitudes :
quant à la façon de nommer les branches, et dans quel cas les créer ou les merge ;
quant au niveau de détail des informations à fournir dans les messages de commit ;
quant à la catégorisation des tâches ;
etc.
Dans ce cas, mettons tout le monde d’accord dès le début, et c’est bon !
Exactement ! Et pour mettre tout le monde d’accord, comme vous dites, il existe des workflows. Découvrons ensemble ce que c’est !
Découvrez les workflows
Git en lui-même ne pousse pas à utiliser un workflow en particulier, car il se veut le plus flexible possible. Ce sont donc les collaborateurs qui décident du workflow à appliquer. Deux options se présentent à eux : créer pour chaque projet son propre workflow, ou bien réutiliser des workflows qui ont fait leurs preuves ! 
Laissez-moi vous présenter les cinq plus connus d’entre eux :
Le workflow centralisé (Centralized Workflow)
Le workflow centralisé est la méthode la plus simple pour utiliser Git. Son principe ? Tous les collaborateurs utilisent la même branche.
Ainsi, on crée d’abord un repository centralisé, qui est ensuite cloné par tous les collaborateurs. Puis, on alimente ce repository par une suite de git pull / git push. Les conflits sont gérés sur la branche main utilisée par tous les collaborateurs.
Le workflow de création de branches de fonctionnalités (Feature Branch Workflow)
Son principe ? Pour chaque nouvelle fonctionnalité, une branche est créée. La branche main ne contient pas de fonctionnalités en cours de développement.
Dans la pratique, on crée un dépôt centralisé, qui est ensuite cloné par tous les collaborateurs. Ensuite, pour chaque fonctionnalité, on crée une nouvelle branche. Lorsqu’une fonctionnalité est terminée, la branche de fonctionnalité doit être mergée sur la branche main via une pull request.
Le workflow basé sur le tronc (Trunk Based Development)
En réponse à la montée en puissance des techniques d’intégration continue et de développement continu, ce workflow est de plus en plus utilisé.
Son principe ? Les opérations de merge sur la branche principale (nommée Trunk) sont à haute fréquence, tout en permettant au trunk d’être toujours opérationnel. On s’inspire ici des principes agiles et de la volonté d’itérer rapidement.
Son principal atout est de résoudre certains inconvénients de GitFlow tels que les branches de fonctionnalités qui s’éternisent dans le temps, ou la complexité qui en découle lors du merge.
Le workflow GitFlow
C’est une évolution du workflow de création de branches de fonctionnalités présentée par Vincent Driessen en 2010 dans l’article (en anglais) “A successful Git branching model”. Son principe ? Définir encore plus précisément les rôles des branches et les interactions entre elles. Je ne vous en dis pas plus, nous découvrirons cet outil en détail dans la suite de ce chapitre. 😃
Le workflow de duplication (Forking Workflow)
Ce workflow diffère des précédents dans la mesure où il peut être combiné avec ceux-ci.
Son principe ? Le gestionnaire du projet crée un dépôt officiel du projet. Chaque collaborateur crée ensuite un double (fork) côté serveur de ce dépôt officiel. Puis, il crée un dépôt local (clone) sur la base du fork. Pour contribuer au dépôt officiel, les collaborateurs utilisent des pull requests. C’est ensuite le gestionnaire du projet qui validera ou non les contributions.
Eh mais attends ! Il n’y aurait pas un rapport entre le fork qu’on a fait au début du cours et le workflow de duplication ?
Je ne peux rien vous cacher ! 
En effet, le workflow de duplication est généralement utilisé dans les collaborations open source. 
Dans ce chapitre, nous allons découvrir plus amplement GitFlow, qui est un workflow très répandu aujourd’hui. Commençons par analyser son fonctionnement grâce au schéma ci-dessous :
GitFlow repose sur le workflow de création de branches de fonctionnalités. Ainsi, on dispose d’une branche par fonctionnalité (de type feature). Mais il introduit également :
une branche, nommée develop, qui sert à intégrer les branches de fonctionnalités ;
des branches de livraison, de type release, qui vont regrouper un ensemble de fonctionnalités identifiées comme finalisées ;
la branche main, qui contient uniquement du code provenant des branches de release ;
des branches dédiées à la résolution des bugs, de type hotfix, pour traiter des bugs détectés dans la branche main.
GitFlow impose une procédure de travail contraignante. Ce qui est un vrai avantage dans les situations suivantes :
vous êtes le gestionnaire d’un projet open source et vous souhaitez contrôler efficacement les contributions ;
vous travaillez avec de nombreux développeurs juniors qui ont besoin d’être cadrés ;
vous cherchez à limiter les risques de corruption sur le code d’un projet d’envergure.
D’un autre côté, cette procédure de travail contraignante peut devenir un réel inconvénient dans les situations suivantes où vous travaillez :
dans une startup qui a une volonté d’aller très vite dans le développement du produit ;
avec des développeurs expérimentées ;
dans un projet où l’agilité et les itérations rapides sont poussées à l'extrême.
Dans ces différentes situations, GitFlow devient un inconvénient, car il induit des latences dans la gestion des branches qui peuvent freiner l’avancée du projet.
Finalement, comme d’habitude, on a les défauts de ses qualités. 
Utilisez les commandes GitFlow
L’un des avantages de GitFlow est que vous pouvez faciliter sa mise en place et, surtout, y ajouter des commandes, en utilisant un plug-in.
Laissez-moi vous faire une démonstration :
Récapitulons ce qui a été réalisé :
Nous avons initialisé notre projet avec git flow init. Cela a eu pour conséquence non seulement de créer la branche main comme nous en avions l’habitude, mais également la branche develop, et de nous positionner sur cette dernière.
Nous avons créé une nouvelle branche de fonctionnalité avec git flow feature start fonctionnalite1. La branche fonctionnalite1 a été créée à partir de develop.
Nous avons réalisé un commit sur fonctionnalite1, puis exécuté git flow feature finish fonctionnalite1. Ainsi la branche fonctionnalite1 a été merge sur develop.
Enfin nous avons créé la release avec git flow release start 0.0.1, et nous l’avons immédiatement intégrée à la branche main avec git flow release finish ‘0.0.1’.
Pour aller plus loin, n’hésitez pas à vous plonger dans la documentation de git flow.
Profitez d’un retour d’expérience avant de vous lancer
Vous voulez vous lancer dans la mise en place de workflow avec GitFlow ? Rien de tel qu’un petit retour d’expérience et quelques conseils pour se jeter à l’eau ! Ainsi, je vous invite à regarder le témoignage de Benjamin Dasnois, développeur Full Stack, sur la mise en place de cet outil.
À vous de jouer
Retournons à notre projet Open Transport ! L’issue 5 attire votre attention, et vous décidez de la traiter. Pour ce faire, vous allez utiliser le workflow GitFlow. Voici les étapes à suivre :
initialisez le repository local avec Git Flow (oui vous pouvez le faire, même s’il s’agit déjà d’un repository Git initialisé) ;
créez une nouvelle branche de fonctionnalité pour l’issue 5 ;
réalisez l’issue 5 et commitez sur la branche de fonctionnalité. Pour vous aider, voici le lien vers le template du fichier .gitignore demandé ;
clôturez cette branche pour l’intégrer sur develop ;
releasez cette fonctionnalité en 0.0.2.
Vous avez réussi ? J’en suis sûr. 
Retrouvez-moi dans la vidéo qui suit pour vérifier votre travail :
Nous avons donc exécuté les commandes ci-dessous :
git flow init ;
git flow feature start issue5 ;
git add * ;
git commit -m “#5 implémentation de la fonctionnalité” ;
git flow feature finish issue5 ;
git flow release start 0.0.2 ;
git flow release finish ‘0.0.2’.
En résumé
Les workflows Git permettent de normaliser l’utilisation de Git au sein d’une équipe ou d’un groupe de collaborateurs.
Les principaux workflows sont :
le workflow centralisé ;
le workflow basé sur la création de branches de fonctionnalités ;
le workflow basé sur le tronc ;
le workflow de duplication ;
le GitFlow.
GitFlow est un workflow répandu qui étend le workflow basé sur la création de branches de fonctionnalités, en normalisant les branches et les interactions entre elles.
Un plugin GitFlow donne accès à des commandes facilitant la mise en œuvre de GitFlow.
Vous savez désormais mettre en place des workflows avec GitFlow, bravo ! Retrouvez-moi dans le chapitre suivant pour automatiser les traitements sur vos projets grâce aux hooks !
