Les stratégies de branches
Comment une équipe organise ses branches Git : Git Flow avec ses cinq familles de branches, GitHub Flow et ses branches courtes, développement sur le tronc ; d'où part et où revient chaque branche, et quelle stratégie choisir.
- 25 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Branche Git : de quoi s'agit-il ?
Voir la réponse
Pointeur mobile vers un commit, qui avance d'un cran à chaque nouveau commit validé dessus.
Une branche ne copie aucun fichier : créer une branche est quasi instantané, et c'est ce qui rend les stratégies de branches possibles.
Dans Git Flow, que contient la branche main ?
- Seulement les versions livrées en production, chacune étiquetée
- Le travail de tous les développeurs, fusionné au fil des jours
- La prochaine version, en cours de stabilisation
- Les corrections urgentes en attente de validation
Voir la réponse
Seulement les versions livrées en production, chacune étiquetée
Le travail courant s'intègre dans develop, la stabilisation se fait dans release : main ne reçoit que des versions terminées, d'où l'étiquette de version sur chaque commit de main.
Dans Git Flow, une branche feature part de … et y revient ; une branche release part de develop et revient dans develop et dans ….
Voir la réponse
Dans Git Flow, une branche feature part de develop et y revient ; une branche release part de develop et revient dans develop et dans main.
La branche release sert à stabiliser une version : seules des corrections y entrent. Quand elle est prête, elle est fusionnée dans main, étiquetée, puis dans develop.
Git Flow : de quoi s'agit-il ?
Voir la réponse
Stratégie à deux branches permanentes, main pour les versions livrées et develop pour l'intégration, complétées par des branches feature, release et hotfix.
Elle convient aux logiciels livrés par versions numérotées, mais elle ajoute des branches et des fusions : c'est lourd pour un site déployé en continu.
Des branches vivent trois semaines et chaque fusion provoque des dizaines de conflits. Quelle est la cause la plus probable ?
- Les branches divergent trop longtemps de la branche commune
- Les développeurs valident trop souvent sur leur branche
- L'équipe compte trop peu de branches permanentes
- Les messages de commit ne suivent pas de convention
Voir la réponse
Les branches divergent trop longtemps de la branche commune
Plus une branche vit, plus les autres modifient les mêmes fichiers entre-temps. La solution : des branches courtes, une intégration fréquente de la branche commune dans la sienne, et des changements découpés en petits morceaux.