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 !
Rien NE va plus dans votre équipe ?
- Le projet part à la dérive ?
- Développé par un-e stagiaire, vous ne savez rien du projet ?
- Personne ne s'écoute dans vos équipes ?
- Vos livraisons échouent souvent ?