3.4 Les branches avec Git - Travailler avec les branches

Comme Git utilise une fusion à 3 sources, fusionner une même branche dans une autre plusieurs fois sur une longue période est généralement facile. Cela signifie que vous pouvez avoir plusieurs branches ouvertes en permanence pour différentes phases de votre cycle de développement. Vous pourrez fusionner régulièrement ces branches entre elles.

De nombreux développeurs travaillent avec Git selon une méthode qui utilise cette approche. Il s’agit, par exemple, de n’avoir que du code entièrement stable et testé dans leur branche master ou bien même uniquement du code qui a été ou sera publié au sein d’une release. Ils ont alors en parallèle une autre branche appelée develop ou next. Cette branche accueille les développements en cours qui font encore l’objet de tests de stabilité — cette branche n’est pas nécessairement toujours stable mais quand elle le devient, elle peut être intégrée (via une fusion) dans master. Cette branche permet d’intégrer des branches thématiques (topic branches : branches de faible durée de vie telles que votre branche iss53), une fois prêtes, de manière à s’assurer qu’elles passent l’intégralité des tests et n’introduisent pas de bugs.

En réalité, nous parlons de pointeurs qui se déplacent le long des lignes des commits réalisés. Les branches stables sont plus basses dans l’historique des commits tandis que les branches des derniers développements sont plus hautes dans l’historique.

Il est généralement plus simple d’y penser en termes de silos de tâches où un ensemble de commits évolue progressivement vers un silo plus stable une fois qu’il a été complètement testé.

Vous pouvez reproduire ce schéma sur plusieurs niveaux de stabilité. Des projets plus gros ont aussi une branche proposed ou pu (proposed updates) qui intègre elle-même des branches qui ne sont pas encore prêtes à être intégrées aux branches next ou master. L’idée est que les branches évoluent à différents niveaux de stabilité : quand elles atteignent un niveau plus stable, elles peuvent être fusionnées dans la branche de stabilité supérieure. Une fois encore, disposer de multiples branches au long cours n’est pas nécessaire mais s’avère souvent utile, spécialement dans le cadre de projets importants et complexes.

Les branches thématiques, elles, sont utiles quelle que soit la taille du projet. Une branche thématique est une branche ayant une courte durée de vie créée et utilisée pour une fonctionnalité ou une tâche particulière. C’est une méthode que vous n’avez probablement jamais utilisée avec un autre VCS parce qu’il y est généralement trop lourd de créer et fusionner des branches. Mais dans Git, créer, développer, fusionner et supprimer des branches plusieurs fois par jour est monnaie courante.

Vous avez déjà vu ces branches dans la section précédente avec les branches iss53 et correctif que vous avez créées. Vous y avez réalisé quelques commits et vous les avez supprimées immédiatement après les avoir fusionnées dans votre branche principale. Cette technique vous permet de changer de contexte rapidement et complètement. Parce que votre travail est isolé dans des silos où toutes les modifications sont liées à une thématique donnée, il est beaucoup plus simple de réaliser des revues de code. Vous pouvez conserver vos modifications dans ces branches pendant des minutes, des jours ou des mois puis les fusionner quand elles sont prêtes, indépendamment de l’ordre dans lequel elles ont été créées ou traitées.

Prenons l’exemple suivant : alors que vous développez (sur master), vous créez une nouvelle branche pour un problème (prob91), travaillez un peu sur ce problème puis créez une seconde branche pour essayer de trouver une autre manière de le résoudre (prob91v2). Vous retournez ensuite sur la branche master pour y travailler pendant un moment puis finalement créez une dernière branche (ideeidiote) contenant une idée dont vous doutez de la pertinence. Votre historique de commits pourrait ressembler à ceci :

Maintenant, supposons que vous décidiez que vous préférez la seconde solution pour le problème (prob91v2) et que vous ayez montré la branche ideeidiote à vos collègues qui vous ont dit qu’elle était géniale. Vous pouvez jeter la branche prob91 originale (perdant ainsi les commits C5 et C6) et fusionner les deux autres branches. Votre historique ressemble à présent à ceci :

Nous verrons au chapitre Git distribué, d’autres méthodes et processus possibles pour vos projets Git. Nous vous invitons à prendre connaissance de ce chapitre avant de vous décider pour une méthode particulière de gestion de vos branches pour votre prochain projet.

Il est important de se souvenir que lors de la réalisation de toutes ces actions, ces branches sont complètement locales. Lorsque vous créez et fusionnez des branches, ceci est réalisé uniquement dans votre dépôt Git local et aucune communication avec un serveur n’a lieu.