Tu travailles sur une refonte de la page d'accueil depuis une semaine.
Les fichiers sont à moitié modifiés, rien ne fonctionne vraiment.
Ton collègue arrive en urgence : un bug bloque les commandes en production, il faut corriger ça maintenant.
Si tu lui passes ton code dans l'état, c'est la catastrophe.
Deux lignes de temps qui coexistent
Créer une branche Git, c'est comme créer une réalité alternative pour le code.
Il faut imaginer Git comme un multivers, comme dans les films de super héros.
Les réalités partagent une histoire commune, mais à un moment, quelqu'un
a fait un choix qui a créé une version alternative. Ces univers évoluent maintenant indépendamment les uns des autres.
Il arrive qu'ils fusionnent. Souvent, tout se passe bien, mais parfois la collision provoque le chaos.
Les développeurs sont les dieux de ce multivers. Ils peuvent revenir dans le temps, naviguer entre les univers, en créer de nouveaux et les
fusionner.
Dans notre exemple :
- Tu sauvegarderais tes développements concernant la page d'accueil sur une branche.
- Tu remonterais ensuite dans le temps, à un état précédent de l'historique Git, jusqu'à ce que le code corresponde à ce qu'il y a actuellement en production.
- Tu résoudrais le bug urgent.
Ce système permet de paralléliser des développements différents. Un développeur seul peut s'en servir pour jongler entre plusieurs tâches.
Une équipe de développeurs peut avancer sur toutes les fonctionnalités en même temps sans que les modifications de l'un n'interfèrent avec le code des autres.
La branche principale s'appelle généralement "main" ou "master".
C'est la version de référence du projet, celle qui correspond à ce qui tourne en production.
Quand quelqu'un commence une nouvelle tâche, il crée sa propre branche depuis main,
travaille tranquillement dessus, puis réintègre le tout quand c'est prêt.
Créer une branche dans Git est quasi instantané et ne coûte presque rien en espace disque.
Git ne duplique pas les fichiers : il retient simplement les différences
à partir du point de divergence.
Le merge : réunir les deux histoires
Réintégrer une branche dans main s'appelle un merge (une fusion).
Git analyse les deux versions et combine les changements.
Si les modifications portent sur des fichiers ou des lignes différentes,
la fusion est automatique. Dans la grande majorité des cas, ça se passe
sans aucune intervention humaine.
Mais si deux personnes ont modifié exactement la même ligne dans deux branches différentes,
Git s'arrête et signale un conflit. Elles doivent combiner manuellement leur travail.
Comment s'organiser avec les branches
Les branches imposent une rigueur d'organisation dans l'équipe. Il faut décider : combien de branches en simultané ? Qui merge quoi, et à quel rythme ? Plusieurs stratégies se sont imposées dans l'industrie.
GitFlow
La plus structurée. En plus de "main", qui représente toujours la production, on maintient une branche "develop"
qui correspond, elle, à la prochaine version du logiciel. Elle contient tous les développements finalisés,
partageables avec tout le monde, prêts à passer en production.
Lorsqu'un développeur commence à travailler sur une nouvelle fonctionnalité, il crée une branche dédiée à partir de develop.
Une fois le code prêt, il est fusionné dans develop.
Quand assez de fonctionnalités sont prêtes à passer en production, une branche de "release" est créée à partir de develop.
C'est une branche figée, parfois pendant plusieurs jours ou semaines, sur laquelle on peut seulement apporter quelques correctifs mineurs.
La release est généralement envoyée sur un environnement de recette ou de préproduction pour être testée par différents métiers.
Pendant ce temps, les développeurs peuvent continuer de faire évoluer la branche develop en toute indépendance.
Une fois la release prête à passer en production, elle est fusionnée sur main pour que le code soit déployé.
Si le développeur avait dû réparer en urgence une anomalie en production (on appelle ça un hotfix), il aurait court-circuité
ce processus et aurait créé une branche partant directement de main.
Le problème majeur du GitFlow : les branches vivent longtemps.
Une branche de fonctionnalité qui traîne trois semaines accumule des dizaines de différences
avec le reste du projet. Le merge final est souvent pénible : plein de conflits, difficile à relire
et risqué parce qu'on découvre les incompatibilités au dernier moment au lieu de les absorber au fil de l'eau.
GitFlow est particulièrement adapté aux organisations qui fonctionnent par versions planifiées.
Il convient bien aux logiciels installés chez des clients, aux contextes réglementaires,
ou aux équipes qui doivent maintenir plusieurs versions en parallèle.
Il apporte un cadre clair et structuré, mais au prix d'une complexité opérationnelle
et d'un risque d'intégration plus élevé.
Trunk-based development
L'approche opposée. Tout le monde travaille quasiment directement sur main.
Les branches sont extrêmement courtes, parfois quelques heures seulement, et l'intégration se fait plusieurs fois par jour.
L'objectif est simple : réduire au maximum l'écart entre le travail en cours et la production.
On intègre immédiatement, on teste automatiquement, on corrige tout de suite.
La revue de code n'est pas obligatoire avant le merge, elle peut avoir lieu après intégration ou être très rapide.
Le contrôle repose avant tout sur l'automatisation des tests et de la surveillance.
Souvent, la fonctionnalité n'est pas totalement terminée.
Ça signifie qu'on passe en production du code invisible pour l'utilisateur.
Ça nécessite un peu d'organisation pour construire dans le bon ordre les pièces du puzzle.
Certaines parties n'ont, de par leur nature, aucun impact tant qu'elles ne sont pas branchées.
D'autres nécessitent la mise en place d'interrupteurs dans le code, qui permettront d'activer ou de désactiver
la fonctionnalité sans redéploiement.
Cette approche est idéale pour les équipes très synchronisées, qui pratiquent le déploiement continu, disposent d'outils et d'une suite de tests robuste.
Elle minimise les conflits d'intégration, mais exige une forte maturité technique.
GitHub Flow
Il est plus encadré que le trunk-based development.
Chaque changement passe par une branche dédiée depuis main et par une demande de merge auprès de l'équipe.
La différence clé est ici : l'intégration ne se fait qu'après validation.
La demande de merge est un point de contrôle formel.
On relit, on discute, les tests sont exécutés.
Les branches restent courtes, mais le merge est conditionné par l'accord de l'équipe.
Cette approche fonctionne très bien dans les équipes distribuées ou quand la revue de code est un pilier fort du fonctionnement.
Elle offre plus de garde-fous que le trunk-based, au prix d'un peu plus de friction avant intégration.
Adapter plutôt qu'appliquer
Ces modèles ne sont pas des dogmes.
GitFlow, trunk-based development et GitHub Flow sont des cadres, pas des lois universelles.
Dans la réalité, beaucoup d'équipes mixent ces pratiques.
L'important est de choisir le modèle qui correspond à votre cadence de livraison, à votre organisation et à votre maturité technique.