Comment bien cadrer son projet avec github flow ?

0
122
github flow

Nous continuons notre série d’articles sur la cohésion technique, autour de Git. Après mentionné l’importance d’un cadrage de vos projets avec Git, nous avions commencé à découvrir les différents flux Git.
Après avoir vu le grand frère git flow, nous allons découvrir ce que Github a choisi pour la gestion de ses projets : le Github flow.

Tout démarre avec la branche master / main

A la différence du git flow, où toute nouvelle foncitonnalité est initialisée depuis la branche de développement, ici, c’est la branche master/main qui sert de référence. Et ça, ça change tout !

Ainsi, une nouvelle fonctionnalité va arriver, vous allez créer une branche spécifique pour cette fonctionnalité.
Vous pouvez ici utiliser la même norme de nommage que pour git flow : à savoir features/{id}-ma-fonctionnalite.

Toute l’équipe va alors récupérer la branche en local, et commencer à développer dessus.
Tout le process normal commit / push / fetch /rebase / pull va être utilisé pour alimenter cette branche.

OK, une fois que c’est ok, que mon travail est ok, comment je l’intègre dans master, via un push, direct, comme ça ?

De l’obligation d’utiliser un Pull / Merge Request

L’important ici, c’est surtout de pouvoir contrôler, valider, ce qui va être envoyé sur la branche master / main !

Et là, au lieu de push directement sur la master, nous allons utiliser la Pull Request (chez gitlab, ça s’appelle une Merge request).

Ainsi, c’est une demande que l’on fait :

  • on requête la branche master/main
  • on propose nos commits pour être tirés (pull) depuis la branche de feature vers la branche master/main

Et c’est bien une vraie proposition 🙂

Dans toute vraie demande, on a le choix :

  • de l’accepter
  • de la refuser
  • de la discuter

Ces trois points sont bien respectés dans une PR/MR (Pull Request / Merge Request).

Accepter une demande

Les personnes, qui ont le rôle, vont pouvoir accepter la PR/MR.

En acceptant, cela va permettre pour la branche réceptrice de récupérer le code qui a été développé par l’équipe.
De plus, on va pouvoir choisir quelle est la stratégie de PR/MP : en pull simple, en rebase, en squash.

Et surtout, cela va laisser une trace, une historique de cette décision !
C’est pourquoi, je vous invite fortement à laisser un commentaire expliquant pourquoi vous valider cette PR/MR !
Soyez le plus verbeux, la plus verbeuse possible !

Refuser la demande

Sur une pièce, nous avons deux faces.

Puisque nous pouvons valider, nous pouvons, fort heureusement, refuser une PR/MR.
Et c’est même essentiel pour la qualité logicielle de votre projet !

Cette PR/MR refusée peut se justifier (avec des explications), car :

  • la revue de code humaine a détecté des erreurs, de la dette technique
  • les vérifieurs automatiques ont ramené des erreurs, des points amélioratifs bloquants, ou jugés comme tel
  • la revue de code a détecté une incompréhension fonctionnelle

Discuter grâce à une Merge / Pull request

Et c’est là, toute la force d’une MR/PR !

Elle ne sert pas qu’à valider ou refuser du code entrant ! Elle permet aussi les échanges, les questions.
Et en posant les questions directement sur la page dédiée de la Pull / Merge Request, on garde là encore l’historique du projet !

Profitez-en !

Un cadre (flow) git, oui mais

On pourrait croire ce cadre parfait. Se dire, hey, c’est génial, avec les PR/MR, on évite de pusher en prod direct.

Oui … mais … dans la vraie vie, on n’a pas toujours le temps de vérifier une PR/MR, on la documente mal, on vérifie mal.
Et une fois qu’elle est validée …. ça part directement en production ! Aouch !!

Rien n’est cadré sur la suite … C’est à vous de décider :

  • créer une branche de release, avant merge sur la main/master (et reprendre le principe git flow) ?
  • la main/master n’est pas la branche de vraie prod, et vous allez alors vous orienter vers gitlab flow, …

Un cadre git simple pour des équipes à faible effectif

On remarque que ce flow git est assez souple, et permet beaucoup de flexibilité, comparé à son grand frère.
Ca amène du bien, comme du moins bien.

  • L’équipe est mature sur git, sur les commits, les puhs, les PR/MR, la qualité logicielle ? Ce cadre est fait pour vous.
  • Votre équipe est nombreuse, c’est alors plus risqué : orientez-vous plus d vers du fork flow par exemple

Bref, on voit qu’on a une bonne base, c’est à vous d’aller l’améliorer, pour coller au mieux à votre entreprise !

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici