Lorsqu'on commence à s'intéresser au contrôle de code source Git, on se pose souvent une question : quel mode d'utilisation dois-je en faire ?

Beaucoup de développeurs viennent du monde centralisé (SVN, TFVC, SourceSafe, ...) et ont une vision orientée. De ce fait, les réflexes et automatismes sont bien là, et on les transpose simplement dans le monde du distribué, sur un dépôt Git.

Sauf que le monde centralisé est tout à fait différent du monde distribué (et ça ne répond pas au même besoin, un n'est pas meilleur que l'autre !). Du coup, il ne faut pas réflechir de la même façon 🤪

Si vous vous êtes un peu penché sur le sujet d'un dépôt Git et comment l'optimiser, vous aller vite tomber sur ces deux termes : Git-Flow et GitHub-Flow. Je ne vais pas refaire l'historique de chacun d'entre eux, je vous invite à vous documenter de votre coté car vous trouverez facilement une multitude de liens sur le sujet. En ce qui nous concerne, allons droit au but !

Les deux workflow Git  répondent à un même besoin : utiliser un mode de travail compatible avec le contrôle de code source Git. Cependant, les deux ne doivent pas être utilisés pour la même chose.

En fait, GitHub-flow est autrement plus simple que Git-Flow. Pourquoi ? Il faut savoir que lorsqu'on crée un dépôt Git, on a une branche par défaut : master. C'est la branche de référence, la seule qui existe au début (à ce moment là de l'histoire, on est exactement pareil qu'un gestionnaire centralisé).

Ce que prône le GitHub-flow, c'est de créer, depuis master, une branche par fonctionnalité (appelée branche feature). Ainsi, lorsque la fonctionnalité est terminée, elle sera réintégrée dans la branche master par le process de Pull Request. Et vous savez quoi ? C'est tout ...

Le lien vers la documentation officielle est ici : https://guides.github.com/introduction/flow/

That's all Folks

Parfait, maintenant que vous avez le générique des Looney Tunes dans la tête, je vais sereinement pouvoir vous expliquer le git-flow 😅

Cette approche est plus complète, mais également plus complexe. Déjà, pour commencer, on va distinguer la branche master d'une autre branche appelée dev. Dans la logique :

  • master = la version actuellement en production
  • dev = la version de travail

Donc on se retrouve avec deux branches au lieu d'une par rapport au modèle précédent. Mais ça ne s'arrête pas là :

  • On va conserver le feature branching, c'est à dire qu'on créera une branche par fonctionnalité (pour développer en autonomie, sans bloquer les autres, et aussi pour profiter du pull-request)
  • On va avoir une notion de branche hotfix, c'est à dire correctif sur la production
  • On aura une notion de branche release, c'est à dire branche pour stabiliser une livraison de version et permettre à l'équipe de continuer l'évolution sans impacter la prochaine version

Atlassian a fait un excellent article sur la question : https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow

Ca, c'est pour la version officielle. Moi, je rajoute un type de branche : les branches fix, qui font des corrections sur une version qui n'est pas en production. Si vous vous demandez pourquoi, je l'explique rapidement sur mon cours Azure DevOps repos, et je l'exploite dans mon cours Azure DevOps pipelines.

Donc on le voit, on n'a pas la même complexité d'un modèle à l'autre.

La question légitime, pourquoi choisir l'un plutôt que l'autre 🤔 ?

C'est très ouvert comme question, et ça dépend vraiment de la typologie de projet et de votre équipe, ainsi que de son expérience avec Git :

GitHub-flow sera un bon choix pour un projet qui ne nécessite pas de phase avancée de validation avant livraison en production, et permettra moins facilement de brancher des automatismes avancés plus fin. A contrario, sa simplicité permettra une adoption plus facile par une équipe ayant été biberonnée au centralisé.

A titre totalement personnel, j'utilise systématiquement le Git-flow, SAUF pour les petits projets qui ne nécessitent pas le côté avancé OU pour les projets (comme ce blog) qui partent d'une base de code suffisamment stable et mature pour éviter d'avoir trop d'opérations à chaque livraison.

Si vous désirez mettre en place le git-flow dans votre organisation en vous servant de la plateforme Azure DevOps, vous pouvez trouver beaucoup plus de détails sur mon cours disponible sur Udemy, ou me contacter directement sur LinkedIn

Comments


Comments are closed