Comparaison des workflows Git : ce que vous devriez savoir

Lorsque vous évaluez un workflow pour votre équipe, le plus important est de tenir compte de votre culture. Votre workflow doit améliorer l'efficacité de votre équipe, sans toutefois compromettre la productivité. Voici quelques points à prendre en considération lorsque vous évaluez un workflow Git :

• Ce workflow s'adapte-t-il à la taille des équipes ?
• Est-il facile de corriger les erreurs et les fautes commises dans ce workflow ?
• Ce workflow impose-t-il à l'équipe une nouvelle charge cognitive inutile ?

Les développeurs commencent par cloner le dépôt centralisé. Dans leurs propres copies locales du projet, ils modifient les fichiers et commitent des changements comme ils le feraient avec SVN ; néanmoins, ces nouveaux commits sont stockés localement. Ils sont totalement isolés du dépôt centralisé. Les développeurs peuvent ainsi reporter la synchronisation amont jusqu'à ce qu'ils atteignent un point d'arrêt pratique.

Pour publier les changements dans le projet officiel, les développeurs font un « push » de leur branche main locale vers le dépôt centralisé. Cette opération est similaire à svn commit, à cela près que tous les commits locaux qui n'ont pas encore été intégrés à la branche main centrale sont ajoutés.

Assurez-vous d'utiliser un nom d'utilisateur SSH valide pour user, le domaine ou l'adresse IP de votre serveur pour host, et l'emplacement dans lequel vous souhaitez stocker votre dépôt pour /path/to/repo.git. Remarque : l'extension .git est habituellement utilisée pour indiquer que le dépôt est brut.

Ensuite, chaque développeur crée une copie de tout le projet en local. Cette opération s'effectue via la commande git clone :

Lorsque vous clonez un dépôt, Git crée automatiquement un raccourci nommé origin qui pointe vers le dépôt « parent », au cas où vous souhaiteriez interagir avec lui à une étape ultérieure.

N'oubliez pas que puisque ces commandes créent des commits locaux, Jean peut répéter ce process autant de fois qu'il le souhaite sans avoir à se soucier de ce qu'il se passe dans le dépôt centralisé. Cela peut s'avérer très utile pour les fonctionnalités volumineuses qui nécessitent d'être divisées en blocs plus simples.

Cette commande fait un push des nouveaux changements commités vers le dépôt centralisé. Lorsque vous faites un push de changements vers le dépôt centralisé, il est possible que des mises à jour d'un autre développeur déjà pushées contiennent du code qui entre en conflit avec les vôtres. Git émet alors un message indiquant ce conflit. Dans cette situation, vous devrez d'abord exécuter la commande git pull. Ce scénario de conflit sera développé dans la section suivante.

Dans la mesure où les développeurs peuvent publier leur fonctionnalité, ils doivent fetcher les commits centraux mis à jour et rebaser leurs changements sur ces commits. Cela revient à dire : « Je veux ajouter mes modifications à tout ce qui été fait par les autres ». Résultat : un historique parfaitement linéaire, comme dans les workflows SVN traditionnels.

Si des changements apportés en local entrent en conflit direct avec les commits réalisés en amont, Git interrompt le rebase pour vous permettre de résoudre les conflits manuellement. L'avantage de Git est qu'il utilise les commandes git status et git add pour générer des commits et résoudre les conflits de merge. Ainsi, les développeurs débutants peuvent gérer leurs propres merges plus facilement. Avec Git, il est en outre très facile d'abandonner complètement un rebase pour effectuer une nouvelle tentative (ou demander de l'aide) en cas de problème.

Dans son dépôt local, Jean peut développer des fonctionnalités en utilisant le processus de commit Git standard : édition, staging et commit.

N'oubliez pas que, puisque ces commandes créent des commits locaux, Jean peut répéter ce processus autant de fois qu'il le souhaite sans avoir à se soucier de ce qui se passe dans le dépôt centralisé.

Dans le même temps, Marie travaille sur sa propre fonctionnalité dans son dépôt local en utilisant le même processus (édition, staging et commit). Tout comme Jean, elle ne se préoccupe pas de ce qu'il se passe dans le dépôt centralisé et elle ne se soucie vraiment pas de ce que Jean fait dans son dépôt local, puisque tous les dépôts locaux sont privés.

Une fois que Jean aura terminé de développer sa fonctionnalité, il devra publier ses commits locaux dans le dépôt centralisé pour que les autres membres de l'équipe puissent y accéder. Pour ce faire, il peut utiliser la commande git push comme suit :

Souvenez-vous qu'origin constitue la connexion distante avec le dépôt centralisé que Git a créé lorsque Jean l'a cloné. L'argument main indique à Git de faire de la branche main d'origin sa branche main locale. Comme le dépôt centralisé n'a pas été mis à jour depuis que Jean l'a cloné, l'opération se déroulera sans conflit, et le push fonctionnera comme prévu.

Voyons ce qu'il se passe si Marie tente de pusher sa fonctionnalité après que Jean a publié ses changements dans le dépôt centralisé. Elle peut utiliser la même commande push :

Mais comme son historique local diverge du dépôt centralisé, Git refusera la requête et renverra un message d'erreur détaillé :

Cela empêche Marie d'écraser les commits officiels. Elle doit faire un pull des mises à jour de Jean dans son dépôt, les intégrer avec ses changements locaux, puis réessayer.

Marie peut lancer git pull pour intégrer à son dépôt les changements effectués en amont. Cette commande est très similaire à svn update : elle fait un pull de tout l'historique du commit en amont dans le dépôt local de Marie et tente de l'intégrer à ses commits locaux :

L'option --rebase indique à Git de déplacer tous les commits de Marie vers la pointe de la branche principale après l'avoir synchronisée avec les changements issus du dépôt centralisé, comme l'illustre le schéma suivant :

Le pull fonctionnera toujours si vous oubliez cette option, mais vous vous retrouverez avec un commit de merge superflu à chaque fois qu'un utilisateur devra synchroniser son dépôt avec le dépôt centralisé. Pour ce workflow, il est toujours préférable de procéder à un rebase plutôt que de générer un commit de merge.

Lors du rebase des projets, chaque commit local est individuellement transféré vers la branche main mise à jour. Cela signifie que vous traitez les conflits de merge commit par commit, plutôt que de les résoudre tous dans un seul grand commit de merge. Vos commits seront aussi orientés que possible, et l'historique de votre projet restera propre. Ainsi, il vous sera nettement plus facile de détecter l'origine de bugs et, si nécessaire, d'annuler les changements tout en limitant l'impact de ces opérations sur l'ensemble du projet.

Si Marie et Jean travaillent sur des fonctionnalités non liées, il est peu probable que le process de rebase génère des conflits. Si c'est le cas, Git interrompt le rebase au commit actuel et affiche le message suivant avec des instructions pertinentes associées :

Le grand avantage de Git est que chaque développeur peut résoudre ses propres conflits de merge. Dans notre exemple, Marie doit simplement exécuter la commande git status pour identifier l'origine du problème. Les fichiers en conflit apparaîtront dans la section Chemins non mergés :

Ensuite, elle modifiera le ou les fichiers à sa convenance. Une fois qu'elle sera satisfaite du résultat, elle pourra stager le ou les fichiers de la manière habituelle, puis laisser la commande git rebase faire le reste :

Le tour est joué. Git passe au commit suivant et répète le process pour tous les commits qui génèrent des conflits.

Si vous n'avez pas la moindre idée de ce qu'il se passe à ce stade, pas de panique ! Il vous suffit d'exécuter la commande suivante pour revenir au point de départ :

Après avoir synchronisé le dépôt centralisé, Marie pourra publier ses changements avec succès :

Comme vous pouvez le voir, il est possible de répliquer un environnement de développement Subversion classique avec seulement quelques commandes Git. C'est intéressant pour la migration d'équipes hors du dépôt SVN, mais cela n'exploite pas la nature distribuée de Git.

Le workflow centralisé est idéal pour les petites équipes. Le processus de résolution de conflits détaillé ci-dessus peut constituer un goulot d'étranglement à mesure que votre équipe s'agrandit. Si votre équipe est à l'aise avec le workflow centralisé, mais souhaite simplifier ses efforts de collaboration, il est sans doute intéressant d'étudier les avantages du workflow de branche de fonctionnalité. En dédiant une branche isolée à chaque fonctionnalité, il est possible d'entamer des discussions approfondies sur les nouveaux ajouts avant de les intégrer au projet officiel.

En bref, le workflow centralisé est un élément de base d'autres workflows Git. Les workflows Git les plus populaires impliquent une forme quelconque de dépôt centralisé à partir duquel les développeurs font des push et des pull. Dans la section suivante, nous allons brièvement évoquer certains autres workflows Git populaires. Ces workflows étendus offrent davantage de modèles spécialisés en ce qui concerne la gestion des branches pour le développement de fonctionnalités et de correctifs et, enfin, la livraison.

La création de branches de fonctionnalité est une extension logique du workflow centralisé. Le principe de base du workflow de branche de fonctionnalité est que chaque fonctionnalité est développée dans une branche dédiée plutôt que dans la branche main. Grâce à cette encapsulation, plusieurs développeurs peuvent travailler aisément sur une même fonctionnalité sans modifier la base de code principale. Cela signifie également que la branche main ne contiendra jamais de code bugué : un avantage non négligeable pour les environnements d'intégration continue.

Le workflow Gitflow a tout d'abord été publié dans un billet de blog très médiatisé de 2010, par Vincent Driessen de chez nvie. Le workflow Gitflow définit un modèle de branches strict conçu autour de la version du projet. Il n'ajoute aucun nouveau concept ni aucune nouvelle commande en dehors de ce qui est exigé pour le workflow de branche de fonctionnalité. Il assigne plutôt des rôles très spécifiques aux différentes branches et définit comment et quand elles doivent interagir.

Le workflow de duplication (fork) est fondamentalement différent des autres workflows abordés dans ce tutoriel. Au lieu d'utiliser un dépôt unique côté serveur qui fera office de base de code « centralisée », ce workflow fournit un dépôt côté serveur à chaque développeur. Par conséquent, chaque contributeur dispose non pas d'un, mais de deux dépôts Git : un local privé et un côté serveur public.

Il n'existe pas de modèle unique de workflow Git adapté à toutes les circonstances. Comme nous l'avons déjà dit, il est important de développer un workflow Git qui améliore la productivité de votre équipe. Outre la culture d'équipe, un workflow doit compléter la culture d'entreprise. Les fonctionnalités Git comme les branches et les tags devraient compléter le planning de livraison de votre entreprise. Si votre équipe utilise un logiciel de gestion de projet et de suivi des tâches, vous souhaiterez peut-être utiliser des branches qui correspondent aux tâches en cours. En outre, voici quelques recommandations à prendre en compte lorsque vous déterminez le workflow à utiliser :

Il est important d'avoir un workflow qui contribue à prévenir, de façon proactive, les merges qui devront être restaurés. Un workflow qui teste une branche avant de permettre qu'elle ne soit mergée dans la branche main, par exemple. Cependant, vous n'êtes pas à l'abri des accidents. Cela dit, il est utile de mettre en place un workflow qui permet des reverts faciles, sans interrompre le travail des autres membres de l'équipe.

Un workflow doit compléter votre cycle de développement et de livraison. Si vous prévoyez de livrer plusieurs fois par jour, il vous faut conserver une branche principale stable. Si votre planning de livraison est moins fréquent, vous souhaiterez peut-être utiliser des tags Git pour taguer une branche à une version.

Dans ce document, nous avons abordé les workflows Git. Nous avons étudié en détail un workflow centralisé avec des exemples pratiques. Pour aller plus loin, nous avons vu des workflows spécialisés supplémentaires. Voici les enseignements clés de ce module :

• Il n'existe pas de modèle de workflow Git universel
• Un workflow doit être simple et améliorer la productivité de votre équipe
• Vos exigences métier devraient vous aider à façonner votre workflow Git

Pour découvrir le prochain workflow Git, consultez notre décomposition détaillée du workflow de branche de fonctionnalité.