Gérer son workflow avec Git

Quel Workflow avec Git​

Introduction​

Mise à part le fait d’être un hébergement meublé touristique ou un morceaux de viande de boeuf situé dans la cuisse, Git est un outils de versionning décentralisé et libre de droit créé par Linus torvald (l’auteur du tout petit noyau de système d’exploitation répondant au nom de Linux).

Utilisé par plus de douze millions de personnes à travers le monde, Git est le logiciel de gestion de version le plus populaire sur la Terre. En 2017, Microsoft quitte le bon vieux Apache Subversion, aka SVN pour migrer le code de Windows vers Git. Microsoft renforce son lien avec git en rachetant, en juin 2018, le site Github pour la modique somme de 7.5 Milliard de dollars.

Mais comment bien gérer son système de branche? Voici une sélection des différentes manières de créer, modifier; bref, gérer ses branches. Il est conseillé de connaître le fonctionnement de Git avant de lire cet article. Pour les néophytes, la documentation officielle est bien écrite.

NoFlow - Utiliser Git comme SVN​​

Cette méthode est la plus simple puiqu’il suffit de publier son travail sur la seule et unique branche existante par défaut : la branche master.

Cette méthode est principalement utilisée par les développeurs solo afin de versionner leur code.

Master

GitFlow - La machine de guerre​

Le principe de GitFlow est de fonctionner sur deux branches principales: la branche de développement (develop) et la branche de production (master).

Chaque nouvelle modification du projet doit être faite via des sous-branches, au nombre de trois, qui sont ensuite fusionnées aux branches principales :

  • Pour ajouter de nouvelle fonctionnalité, il faut créer une branche “feature”. Elle sera ensuite ajoutée à la branche develop ou à une branche de release.
  • Si on souhaite fixer une erreur sur la branche master, il faut créer une nouvelle branche “hotfix”. Cette dernière sera fusionnée sur les deux branches principales.
  • Dès que l’on souhaite créer une release, on créé une branche “release” qui sert de branche principale aux nouvelles fonctionnalité de cette dernière. Lorsque la release arrive en production, les commits de cette branches sont rajoutés à la branche master ainsi qu’à la branche develop pour permettre de continuer aisément le développement de nos fonctionnalités sans problèmes majeurs lors des futures fusion de branche.

La convention de nommage des sous-branche consiste à les appeler selon leur fonctionnalité première (“feature”, “hotfix”, “release”) suivi du numéro du ticket, ou son nom, sa fonctionnalité, etc… (example: “feature-1”)

Workflow

ReleaseFlow- Git flow sur une branche principale​

Le principe de fonctionnement de ReleaseFlow est qu’il est une amélioration de Git Flow, le changement majeur étant qu’il n’existe pas de branche develop.

Le principal avantage est d’avoir un historique Git plus propre tout en conservant ceux de Git Flow.

Oneflow

Gitlab Flow - Ma pré-prod contient précisément ces commits​

A l’instar de tous les autres workflow, GitLab Flow a sa propre branche de production dont le dernier commit sur cette fameuse branche est la version actuelle du service. GitFlow est lui aussi est basé sur trois branches principales :

  • La branche master, qui représente l’environnement de développement
  • La branche staging, qui représente le contenu de la version de pré-production
  • La branche Production, qui est la version publie sur les serveurs de production

L’avantage d’utiliser ce workflow est qu’il est possible de déterminer les commits utilisés dans chaque environnement.

Gitlab Flow

GitHub Flow - Qui peut mettre en prod mon code ?​​

Le site Github implémente le système de Pull Request en 2008. Cette ajout fut une révolution pour les projets open-source en permettant à un utilisateur de pouvoir fusionner son code dans une autre branche à la suite d’une validation manuelle d’une ou plusieurs personnes.

Github Flow place au coeur de son workflow le Pull Request. Le développeur créé une nouvelle branche sur laquelle il va faire ses modification. Après avoir fini son développement, le développeur crée une pull request. Tant que la demande n’as pas été validée par l’équipe, le développeur peut modifier son code. Si l’équipe valide la modification, cette dernière est fusionnée au code principal. La branche principal du projet est donc fonctionnelle et livrable en production.

githubflow

Trunk Based Development - Tout sur master​​

La différence majeur, entre le trunk-based et Github Flow, est que la branche master n’est pas considérée comme utilisable en production. Toutes les fonctionnalités sont ajoutées à la branche principale, et seuls les commits de corrections sont ajoutés à la branche de release (après avoir été ajoutés au trunk).

Cette pratique permet d’éviter les conflits de merge et de garder un programme compilable et fonctionnel.

trnk base development

Conclusion

La différence majeur, entre le trunk-based et Github Flow, est que la branche master n’est pas considérée comme utilisable en production. Toutes les fonctionnalités sont ajoutées à la branche principale, et seuls les commits de corrections sont ajoutés à la branche de release (après avoir été ajoutés au trunk).

Cette pratique permet d’éviter les conflits de merge et de garder un programme compilable et fonctionnel.

Notez cet article
0/5

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *