Post on 18-Jun-2020
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement
Guide d’utilisation Modèles de branchement
1 Guillaume HARRY | Contenu sous licence Creative Commons CC-BY-NC-ND
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 2
1. Git Flow
2. GitHub Flow
3. GitLab Flow
Sommaire
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 3
Modèle de branchement Git Flow
Publié par Vincent DRIESSEN http://nvie.com/posts/a-successful-git-branching-model/
2 branches permanentes
1 développement = 1 branche dédiée explicite
Outil git-flow (https://github.com/nvie/gitflow) simplifie la mise en œuvre de ce modèle
Particulièrement adapté aux méthodes agiles
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 4
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 5
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 6
Modèle de branchement Git Flow
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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 7
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 8
Modèle de branchement GitHub Flow
Publié par Scott Chacon http://scottchacon.com/2011/08/31/github-flow.html
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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 9
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 10
Modèle de branchement GitLab Flow
Publié par Sytse Sijbrandij https://about.gitlab.com/2014/09/29/gitlab-flow/
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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 11
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 12
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 13
Modèle de branchement 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
Janvier 2015 Guillaume HARRY | Guide d’utilisation Git : Modèles de branchement 14
A chacun de choisir et
adapter un modèle de
branchement selon la nature
du projet
Conclusion