Guide d utilisation. Modèles de branchement

Transcription

1 Guide d utilisation Modèles de branchement 1 Guillaume Guillaume HARRY HARRY Contenu Guide sous d utilisation licence Creative Git : Modèles Commons de branchement CC-BY-NC-ND

2 Sommaire 1. Git Flow 2. GitHub Flow 3. GitLab Flow 2

3 Git Flow Publié par Vincent DRIESSEN 2 branches permanentes 1 développement = 1 branche dédiée explicite Outil git-flow ( simplifie la mise en œuvre de ce modèle Particulièrement adapté aux méthodes agiles 3

4 Git Flow Branche «master» Historique des versions utilisables en production Ne contient que des versions utilisables en production HEAD pointe sur la dernière version utilisable en production ATTENTION Aucun développement n est réalisé sur master Le premier commit contient o Fichier de description README o Fichier des exclusions.gitignore Branche «develop» Historique de TOUS les développements Intégration des différentes fonctionnalités et corrections réalisées HEAD représente l avancement des développements Pour la créer sur le dépôt central : git branch develop git push -u origin develop 4

5 Git Flow Développement de fonctionnalités : branches «feature» Correspond généralement à 1-2 jours de travail sur une partie de «story» Chaque fonctionnalité est développée dans une branche dédiée Créer la branche à partir des développements les plus récents git fetch origin git checkout -b nom_fonctionnalite develop Partager la branche avec les autres développeurs (optionnel) git push origin nom_fonctionnalite Développer la fonctionnalité Mettre à jour la branche locale develop pour faciliter la fusion git pull origin develop Fusionner la fonctionnalité dans les développements git checkout develop git merge nom_fonctionnalite Supprimer la branche devenue inutile git branch -d nom_fonctionnalite Partager les modifications git push origin develop 5

6 Git Flow 6 Réalisations de versions de livraison : branches «release» Sert à l intégration des fonctionnalités et à la correction des bugs Ne contient aucun développement de fonctionnalités Peut être utilisée pour la recette technique et fonctionnelle Chaque livraison est développée dans une branche dédiée Créer la branche avec la convention release-version, en incluant toutes les fonctionnalités git fetch origin git checkout -b release-x.y develop Réaliser les corrections nécessaires et mettre à jour le README Intégrer la version dans la branche master avec l'option «--no-ff» pour tracer la fusion git checkout master git merge --no-ff release-x.y Tag de la version git tag -a x.y Envoyer le contenu de master sur le dépôt central git push --tags Intégrer la version dans la branche develop git checkout develop git merge --no-ff release-x.y git push origin develop Supprimer la branche devenue inutile git branch -d release-x.y

7 Git Flow Corrections de la production : branches «hotfix» Utilisée uniquement pour corriger immédiatement la version en production Permet d isoler le correctif de production du cycle de développement normal du produit Chaque correctif est développé dans une branche dédiée Processus de développement : Créer la branche à partir du master git checkout -b hotfix-x.y.z master Réaliser les corrections nécessaires et mettre à jour le README Intégrer le correctif dans la branche master avec l'option «--no-ff» pour tracer la fusion git checkout master git merge --no-ff hotfix-x.y.z git tag -a x.y.z git push --tags Intégrer le correctif dans la branche develop git checkout develop git merge --no-ff hotfix-x.y.z git push origin develop Supprimer la branche devenue inutile git branch -d hotfix-x.y.z 7

8 GitHub Flow Publié par Scott Chacon 1 branche permanente 1 développement = 1 branche dédiée explicite N intégrer le développement qu après une revue de code par un valideur Aucun développement n est réalisé sur master Particulièrement adapté au DevOps et au déploiement continu 8

9 GitHub Flow Branche «master» Historique des versions utilisables en production Intégration des différentes fonctionnalités et corrections réalisées HEAD pointe sur la dernière version stable utilisable en production Développement de fonctionnalités : branches «feature» Correspond généralement à 1-2 jours de travail sur une partie de «story» Chaque fonctionnalité est développée dans une branche dédiée Chaque ajout/modification est développée dans une branche dédiée explicite git checkout -b nom_fonctionnalite master Partager la branche avec les autres développeurs régulièrement git commit git push origin nom_fonctionnalite Dès que le nouveau code est prêt et stable, demander une revue de code pour validation («pull request» pour GitHub et BitBucket) Le valideur fusionne la branche dans master Télécharger le nouvel état de la branche master git fetch origin Supprimer la branche devenue inutile git branch d nom_fonctionnalite Déployer dans le serveur d intégration continue 9

10 GitLab Flow Publié par Sytse Sijbrandij 1 branche permanente 1 développement = 1 ticket = 1 branche dédiée explicite 1 branche par version stable Compromis entre les modèles Git Flow et GitHub Flow Particulièrement adapté aux méthodes agiles et au déploiement continue 10

11 GitLab Flow Développement de fonctionnalités : branches «ticket» N intégrer le développement qu après une revue de code par un valideur Chaque fonctionnalité est développée dans une branche dédiée Créer un ticket dans le gestionnaire de code pour décrire le besoin Chaque ajout/modification est développée dans une branche dédiée explicite (nom commence par n ticket suivi du descriptif) git checkout -b n _ticket-nom_fonctionnalite master Partager la branche avec les autres développeurs régulièrement git commit git push origin n _ticket-nom_fonctionnalite Dès que le nouveau code est prêt et stable, demander une revue de code («merge request» pour GitLab et Gitorious) Le valideur fusionne la branche dans master Supprimer la branche devenue inutile git branch d n _ticket-nom_fonctionnalite Branche «master» Historique de TOUS les développements Intégration des différentes fonctionnalités et corrections réalisées Aucun développement sur master HEAD représente l avancement des développements 11

12 GitLab Flow Réalisations de versions de livraison : branches «stable» Sert à l intégration des fonctionnalités et à la correction des bugs Ne contient aucun développement de fonctionnalités HEAD représente l état le plus stable de la version Peut être utilisée pour la recette technique et fonctionnelle Supprimer la branche uniquement quand la version ne doit plus être utilisée Processus de développement : Créer la branche avec la convention version-stable, en incluant toutes les fonctionnalités git checkout -b x.y-stable master Réaliser les corrections nécessaires et mettre à jour le README Tag de la version git tag -a vx.y.0 git push --tags Intégrer la version dans la branche master avec l'option «--no-ff» pour tracer la fusion git checkout master git merge --no-ff x.y-stable Déployer la nouvelle version 12

13 GitLab Flow Corrections de la version : branches «hotfix» Utilisée uniquement pour corriger immédiatement la version en production Permet d isoler le correctif de production du cycle de développement normal du produit Chaque correctif est développé dans une branche dédiée Processus de développement : Créer la branche à partir de la branche de livraison git checkout -b hotfix-x.y.z x.y-stable Réaliser les corrections nécessaires et mettre à jour le README Intégrer le correctif dans la branche version-stable avec l'option «--no-ff» pour tracer la fusion git checkout x.y-stable git merge --no-ff hotfix-x.y.z git tag -a vx.y.z git push --tags Intégrer la version dans la branche master avec l'option «--no-ff» pour tracer la fusion git checkout master git merge --no-ff x.y-stable Supprimer la branche devenue inutile git branch -d hotfix-x.y.z 13

14 Conclusion A chacun de choisir et adapter un modèle de branchement selon la nature du projet 14