Comment bien cadrer son projet Git avec ForkFlow

0
173
git forkflow

Nous finissons notre série sur la cohésion technique grâce à Git, avec un cadrage (Flow) Git plus élaboré : le ForkFlow. Comment construire une communauté Open Source sur un projet Git, pouvoir permettre à chacun, chacune d’ajouter du code, donc de contribuer, tout en validant ce qui va être intégrer, voilà les promesses du Fork Flow !

Prendre les principes du Github et Gitlab Flow …

Prenons ce qui fonctionne bien, voire très bien :

  • La possibilité d’avoir un tronc commun (la branche master / main), comme dans Github flow , ou GitLab Flow
  • Pouvoir proposer des Pull/Merge Request avant chaque push réel (pour passer d’une branche de fonctionnalité à la branche master/main)

Et étendons-là pour permettre le travail en grand nombre

L’idée ici, c’est de permettre à chaque développeur, développeuse, d’avoir son propose répository :

  • Local, comme on fait à l’habitude, via le git clone
  • Mais aussi à distance !

Tout se passe via la notion de Fork

Tout d’abord, créez votre repository, sur github, sur gitlab ou bitbucket. Ce sera votre repository commun Git pour toute la communauté.

Depuis ce repo commun, vous allez pouvoir dupliquer le repository, à distance.
Cette action est appelée fork dans les plateformes actuelles.

Ainsi, après ce fork, vous vous retrouvez avec un repository à vous, ET qui est lié au repository global.

Mise en place d’un système triangulaire

Depuis votre repository (venant du fork), vous allez pouvoir :

  • Faire des push
  • Faire des pulls

Toutes ces actions se faisant comme si vous n’étiez pas lié à un repository global.

Cependant, depuis votre repository, à distance, vous allez pouvoir effectuer des demandes pour modifier le code du repository global !
Et c’est là tout le secret !

Via des Pull / Merge Request, vers le repository global, vous gardez ainsi le principe du GitLab Flow (et du GitFlow) !

Et la communauté responsable du code global va avoir la possibilité :

  • De contrôler ce qui a été réalisé
  • De lancer une revue de code
  • De valider / invalider le code à merge / squasher / rebaser
Image for post

Et depuis votre machine, sur le git local, vous allez pouvoir récupérer tout ce qui a été réalisé par la communauté ! Tout ceci grâce à un git pull, sur non pas l’origin, mais l’upstream !

Bon pour la cohésion d’équipe ?

En prenant les bases du cadrage Gitflow (ou de Gitlab flow), on a déjà de très bonnes pratiques avec les Pull / Merge Request.

En l’étendant à la possibilité de ne pas devoir tous et toutes pusher sur le même répository, on amène une plus grande souplesse dans la réalisation de projet. Et donc ce type de cadrage Git est vraiment dédié aux projets :

  • Open-source : où le développement est dit asynchrone
  • Avec de grandes équipes
  • Ou bien pour des projets où les équipes ont plusieurs machines (télétravail, post et home office)

LAISSER UN COMMENTAIRE

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