Git Workflows

Aujourd’hui nous allons parler de workflow git. Un workflow est un ensemble de pratique, de règle, et de procédure qui définit comment une ou des équipes collaborent autour de leur projet avec Git. Il en existe plein, car il existe plein de manière de travailler avec git, en fonction des besoins et en fonction des organisations. Aujourd’hui, du plus simple au plus pratique, nous allons en voir quatre, dont mon préféré le Github Flow.

Workflow Linéaire

Tout le travail est fait sur la branche principale. Ce workflow est idéal pour les petits projets personnels. Si plusieurs personnes travaillent en même temps en utilisant ce workflow, cela va vite devenir douloureux à cause des “merge conflict” récurrents. Aussi la branche principale représentant la production, les nouvelles versions doivent être testées avant d’être push sur la branche principale, donc probablement en locale, ce qui limite les possibilités.

GitFlow

Ce workflow est utilisé pour les cas où il y a plusieurs cycles de release en parallèle et avec des timelines différentes.

Le principe c’est qu’il y a plusieurs branches sur le long terme. Souvent une branche appelée prod pour représenter le code présent en production. De cette branche, ne partent que deux types de branche. Celle pour les correctifs, déployés directement sur le code en production, des Hot-Fix. Et la branche de développement, la version n+1, souvent appelée dev.

A partir de cette branche on trouve des branches de features dans lequel les nouveaux développements sont faits, des branches de fix.

A mesure que l’on approche de la release de la nouvelle version en production, les différents environnements de test sont installés à partir de la dev.

Au moment de la mise en production, la branche de développement est mergée dans la branche principale et un nouveau cycle de développement redémarre.

Ces cycles sont souvent longs (plusieurs mois) et ainsi assez inadaptés au principe DevOps, où l’on veut déployer en production souvent pour avoir des petits changements incrémentaux plutôt que d’énormes changements tous les 6 mois.

Ce type de workflow est fait pour des projets dont c’est le seul moyen de gérer leur différentes releases, car c’est plutôt lourd à maintenir et assez loin du mouvement DevOps.

Le Forking Workflow

Ce workflow est le plus souvent utilisé dans les projets Open Source. En effet, avec beaucoup de contributeurs d’horizons différents, il est plus simple que chacun fork– fassent une copie du code dans leur dépôt – et travaillent directement sur leur copie dans des branches de feature ou de fix. Une fois leur travail terminé, ils peuvent proposer leur modification directement au projet mère.

L’avantage de ce genre de workflow est que les contributeurs sont isolés de manière assez naturelle puisqu’ils travaillent dans leur projet personnel. Cela permet d’éviter de donner des droits sur le repository a des contributeurs inconnus. Aussi, ça ne verrouille pas la contribution a uniquement des membres actifs de la communauté. N’importe qui peut contribuer et proposer ses changements de manière totalement asynchrone.

Sinon pour des projets internes à une organisation, sans visée Open Source, cela duplique beaucoup le code dans des dépôts personnels et cela rajoute une couche de complexité inutile.

GitHub Flow

Dans ce workflow, la branche principale représente l’état actuel des environnements de test et de production. Tous les développements se font dans des branches séparées et temporaires.

Seule la branche principale est pérenne dans le temps.

Tout développement avant d’être mergé dans la branche principale est expliqué au travers d’une Pull Request (PR) et doit être approuvé par un nombre minimum de pairs définis par les équipes.

Ce workflow est souvent utilisé dans des environnements où la transformation DevOps est etablie et où aller régulièrement en production est la règle.

C’est un workflow plus simple que le Gitflow et plus pratique a bien des égards que le premier workflow.

Choisir un workflow adapté au besoin du ou des projets et avoir de l’adhésion autour d’un ensemble de règles communes est primordial pour collaborer efficacement. J’espère que vous avez à présent une vue plus détaillée et précise de ces quatres workflow Git et que cela vous aidera à choisir le bon. Gardez aussi à l’esprit que vous pouvez faire évoluer votre pratique en fonction des besoins de votre projet, et que vous pouvez revenir à tout moment dessus.