Le « forking Workflow » ou « GitHub Flow »

Comme cela a été présenté dans notre comparatif des workflows Git, celui dans lequel nous allons entrer en détails aujourd’hui est particulièrement adapté à une équipe à taille humaine qui pratique des mises en production régulières.

Le concept complet de ce workflow est décrit dans ce tutoriel, à lire en priorité. Si vous avez besoin d’une user-story, le guide Atlassian vous sera probablement utile.

Un article sur GitHub récapitule les six étapes du GitHub Flow. Cette animation web permet même de visualiser le process.

Les commandes principales

Pour résumer, tout commence par la création d’une branche :

Au contraire de git branch, cette commande vous bascule immédiatement dans la branche fraichement créée, basée sur Master. Vous pouvez apporter des modifications à votre arbre de travail, commiter, pusher :

Lorsque votre fonctionnalité est terminée, déplacez vous dans le Master pour tirer vos modifications dedans :

C’est à cet instant que vous aurez éventuellement à résoudre des conflits. Pas d’inquiétude, vous serez toujours en local. Pour déployer votre merge en production, faites tout simplement :

Ce merge ajoute l’intégralité de l’historique d’une branche au master.

À noter que la commande précédente, sans paramètre, poussera toujours le contenu de votre branche master locale dans la branche master sur le serveur, peu importe si vous travaillez dans une autre branche.

Les autres commandes

Pour rafraichir votre branche avec un master qui a évolué :

Un simple git rebase master impliquerait que votre master local soit à jour. Un git merge origin/master créerait un nouveau commit.

Pour lister toutes les branches locales/distantes (-a all, -r remote) :

Pour récupérer la branche d’un collègue :

L’usage des tabulations peut provoquer des erreurs car les noms des branches sont proposés au format « origin/nom » et non « nom ».

Pour supprimer votre branche locale mais conserver la distante :

Pour supprimer la branche distance mais conserver votre locale :

Choisir un Workflow Git adapté à votre équipe

Le site Atlassian a récemment mis à jour son comparatif des différents workflows Git, véritable référence en la matière. Ce guide permet d’étudier les quatre principaux workflow.

Le workflow centralisé

Workflow Git Centralisé
Il s’agit de la manière la plus basique d’utiliser Git, utilisée en découvrant l’outil et le plus souvent souvent seul ou à tour de rôle. Son fonctionnement est simple, résistant aux problèmes, il se répare vite mais laisse entre contrepartie un Master potentiellement instable.

Les branches par fonctionnalités

Workflow Git Branches par fonctionnalités
Ce workflow est très proche du workflow centralisé, mais il introduit une notion importante : le Master doit rester stable en toute circonstance. Le développement s’effectue dans des branches qui sont créées au début de chaque nouvelle fonctionnalité. Le merge d’une fonctionnalité dans le Master n’a lieu que lorsqu’elle est finalisée et qu’elle a été testée.

Ce workflow offre la possibilité de se passer des modifications entre développeurs sans les déployer en production, ou de travailler à plusieurs en parallèle sans être parasité par des évolutions inachevées.

Le Gitflow

Gitflow
Ce workflow rajoute au précédent un dédoublement du Master en Master/Development ou Master/Release/Development voire Master/Hotfix/Release/Development selon la complexité souhaitée.

Ce workflow induit la notion de version sur le Master : des fonctionnalités sont regroupées avant un merge dans Release puis dans Master. La branche Development devient le lieu d’intégration des fonctionnalités.

Le workflow par clonage

Forking workflow
Ce dernier workflow peut être utilisé en partant d’un des deux précédents workflows : les branches de fonctionnalités sont simplement remplacées par des dépôts privés forkés par les développeurs. Le but est uniquement de restreindre les droits des contributeurs au projet (lecture seule sur le dépôt central) qui est administré par un mainteneur.

Dans ce modèle, les fonctionnalités sont signalées par des merge-requests sur une interface où le mainteneur peut faire une revue de code.

Conclusion

Choisir un workflow n’est pas chose évidente : tout dépend de la manière dont vous devez livrer votre projet ainsi que du niveau de confiance que vous avez en vos contributeurs.

Les workflows centralisés ou de branches par fonctionnalités sont bien adaptés au travail d’une équipe de développement à taille humaine. Les workflows type Gitflow ou par clonage (forking) sont adaptés au travail contraint par la livraison de versions stables, ou dans un contexte où des développeurs qui ne se connaissent pas doivent pouvoir coopérer.

Scott Chacon, développeur chez GitHub, a mis en avant l’inadaptation du Gitflow dans leur équipe. Il préfère à cela le GitHub Flow qui n’est rien de plus que le workflow de branches par fonctionnalités.