# Git : stratégies de branches, trunk-based et revue de code Informatique de gestion · Bachelor 2 > Gestion de versions avec Git : branches, trunk-based development et revue de code. ## Introduction La gestion de versions est le socle de la collaboration en développement. Avec Git, chaque développeur travaille sur une copie locale complète du dépôt et crée des branches : lignes de développement parallèles que l'on fusionne ensuite. La question d'organisation est de savoir combien de branches avoir, combien de temps elles vivent et comment elles sont intégrées. GitFlow utilise plusieurs branches durables (développement, versions, correctifs) et convient aux produits livrés par versions. Le développement sur tronc (trunk-based development) privilégie une branche principale et des branches très courtes, voire des commits directs, avec des drapeaux de fonctionnalité pour masquer le travail inachevé. Il facilite l'intégration continue car les écarts restent petits. La pull request (ou merge request) soumet une modification à la revue d'un pair avant fusion. Une bonne revue porte sur la lisibilité, les tests et les risques, sur de petits changements, et s'appuie sur des contrôles automatiques pour libérer les relecteurs des vérifications mécaniques. ## Objectifs d'apprentissage - Expliquer ce qu'est une branche et une fusion - Comparer GitFlow et le développement sur tronc - Décrire le lien entre durée de vie des branches et conflits - Mener une revue de code efficace - Choisir une stratégie adaptée au contexte de livraison ## Concepts clés - **Branche** : Ligne de développement indépendante qui permet de travailler sans perturber la branche principale. - **GitFlow** : Modèle à branches durables (développement, versions, correctifs), adapté à des livraisons par versions. - **Développement sur tronc** : Intégration très fréquente dans une branche principale, avec des branches de courte durée et des drapeaux de fonctionnalité. - **Pull request** : Demande de fusion accompagnée d'une revue et de contrôles automatiques avant intégration. - **Petits changements** : Plus une modification est petite, plus elle est facile à relire, à tester et à annuler. ## Conclusion Aucune stratégie de branches n'est universelle : GitFlow structure des livraisons par versions, tandis que le développement sur tronc favorise un flux continu et une intégration fréquente. Dans les deux cas, plus les branches sont courtes et les changements petits, plus l'équipe va vite en sécurité. La revue de code, outillée par des contrôles automatiques, partage la connaissance et améliore la qualité avant la production. ## Cartes ### Qu'est-ce qu'une branche Git ? Une ligne de développement indépendante, légère à créer, qui permet d'isoler un travail avant de le fusionner. ### Qu'est-ce qu'un conflit de fusion ? Une situation où deux branches ont modifié les mêmes lignes de façon différente ; Git demande une résolution humaine. ### Qu'est-ce qu'une pull request ? Une demande de fusion d'une branche, soumise à discussion, revue et contrôles automatiques avant intégration. ### Quelles branches GitFlow définit-il ? Une branche principale, une branche de développement, des branches de fonctionnalité, de version (release) et de correctif (hotfix). ### Pour quels contextes GitFlow convient-il ? Pour des produits livrés par versions numérotées et plusieurs versions maintenues en parallèle, comme un logiciel installé chez des clients. ### Qu'est-ce que le développement sur tronc ? Une pratique où tous les développeurs intègrent au moins une fois par jour dans une branche principale, avec des branches très courtes. ### Comment masque-t-on un travail inachevé sur le tronc ? Avec des drapeaux de fonctionnalité qui désactivent le nouveau code tant qu'il n'est pas prêt. ### Pourquoi les branches longues sont-elles risquées ? Plus elles divergent, plus la fusion est difficile : conflits nombreux, régressions tardives, intégration douloureuse. ### Que doit apporter une bonne revue de code ? Un regard extérieur sur la clarté, la correction, les tests et la sécurité, avec des remarques précises et courtoises. ### Pourquoi faire de petites pull requests ? Elles se relisent plus vite et plus attentivement, se testent mieux et se retirent facilement en cas de problème. ## Glossaire - **Branche** : Ligne de développement parallèle dans un dépôt. - **Fusion (merge)** : Intégration des modifications d'une branche dans une autre. - **GitFlow** : Modèle de branchement avec branches durables de développement, de version et de correctif. - **Trunk-based development** : Pratique d'intégration quotidienne dans une branche principale avec branches courtes. - **Pull request** : Demande de fusion soumise à revue. - **Revue de code** : Examen d'une modification par un pair avant son intégration. https://ruvy.ch/decks/-P5D-zwFnW-m5BIhT8zs