Comment mettre à jour et maintenir des branches Git distinctes

L'une des principales fonctionnalités de Git est la possibilité de créer plusieurs versions de votre projet. Souvent, ceux-ci sont utilisés pour des fourches à court terme appelées «branches de fonctionnalités», qui sont fusionnées dans master. Cependant, il est parfois nécessaire d'avoir des branches vraiment séparées, ce qui rend plus difficile leur synchronisation.

Pourquoi maintenir différentes succursales ?

Habituellement, les branches sont de courte durée et destinées à être fusionnées dans la branche principale de la version. Dans certains cas cependant, il est nécessaire de maintenir des branches entièrement séparées. Par exemple, vous pouvez avoir des branches ciblant différentes plates-formes ou dépendances, avec des fonctionnalités différentes, ou simplement des branches de version distinctes que vous maintenez en vie pendant un certain temps.

Il s'agit du même flux de travail avec la plupart des forks, et selon la quantité et la gravité des modifications, il peut être difficile de rester synchronisé avec l'amont. Si vos deux branches sont en grande partie synchronisées moins quelques commits, vous aurez beaucoup plus de facilité à gérer les conflits et à garder les choses à jour.

Dans la plupart des cas cependant, vous devriez rechercher des alternatives à la séparation des branches, car cela peut devenir assez fastidieux, en particulier avec les conflits de fusion et tous les tests supplémentaires. Par exemple, si vous avez deux builds ciblant différentes plates-formes, de nombreux langages ont une configuration de build et des préprocesseurs qui peuvent gérer cela. C# a #if NETVERSION, qui permet de modifier le code en fonction de la plate-forme pour laquelle il compile.

Quelle que soit votre raison, il s'agit d'un flux de travail Git valide que de nombreuses personnes utilisent.

Synchroniser les succursales avec le rebasage

Il existe essentiellement deux options pour savoir comment procéder. La première méthode et la plus courante est le rebasage, qui ressemble beaucoup à la fusion, mais permet aux branches d'être complètement indépendantes.

Vous pouvez considérer les commits Git comme une chaîne de changements remontant dans le temps, chacun pointant vers le commit précédent. Lorsque vous créez une nouvelle branche, elle se détache de la branche principale master à un point spécifique, la base de la branche.

Le rebasage consiste essentiellement à soulever toute la branche feature et à la déplacer vers un nouveau point dans le temps, où la fin de celle-ci pointe vers une chaîne de commits différente. Ceci est particulièrement utile si la branche dérivée ne contient que quelques commits, car les conflits de fusion seront alors plus faciles à résoudre. Dans cet exemple, le rebasage de cette branche incorpore les commits B et C, mais pas D et E, car il n'est pas nécessaire de rebaser sur le HEAD de la branche.

Cependant, le changement de base n'est généralement utilisé que pour les branches locales et présente quelques problèmes lorsqu'il est utilisé avec des branches partagées. Les commits ne bougent pas réellement ; ils sont copiés, ce qui entraîne de nouveaux ID de validation, le HEAD de la branche étant déplacé vers le nouvel emplacement.

Cela signifie que les anciens commits restent bloqués. Étant donné que Git est un système de contrôle de version décentralisé, vos collègues peuvent avoir des commits non poussés qui font référence à ces commits supprimés. Le changement de base devra être quelque chose que vous coordonnerez avec tous les collaborateurs, et si quelqu'un a des conflits, il devra le résoudre localement en copiant ces modifications au bon emplacement.

Rebaser une branche est assez facile. Vous devrez vérifier la branche feature, extraire toutes les modifications de votre télécommande, puis exécuter rebase  pour déplacer la feature branche sur la branche cible.

git checkout feature
git pull
git rebase master

Cela entraînera probablement des conflits de fusion, que vous devrez résoudre vous-même, puis valider les modifications.

Alors que la plupart des tâches Git quotidiennes peuvent être effectuées assez facilement à partir de la ligne de commande, le rebasage est par nature une opération assez visuelle, nous vous recommandons donc d'utiliser un client GUI Git comme Fork ou GitKraken si vous le pouvez. Cela vous montrera les embranchements et vous aidera à planifier le rebasage plus efficacement, et peut même effectuer des rebasages interactifs.

Étant donné que le rebasage applique essentiellement chaque commit de la branche de fonctionnalité à un nouvel emplacement, vous n'avez pas besoin de tous les inclure, et le rebasage interactif peut supprimer les commits dont vous n'avez pas besoin. Il est possible de le faire à partir de la ligne de commande, mais cela a plus de sens à partir d'une interface graphique.

Correction des commits indésirables

Que se passe-t-il si vous ne souhaitez pas inclure certains commits lorsque vous rebasez ? Si vous avez des commits sur votre branche feature que vous souhaitez exclure lors du rebasage sur master, alors vous pouvez faire un rebase interactif. Cela supprimera les commits indésirables lors du rebasage, les supprimant essentiellement de l'historique.

Mais, il est beaucoup plus probable qu'il y ait des commits sur la branche master que vous préféreriez ne pas avoir sur votre branche feature. Étant donné que le rebasage définit la base de la nouvelle branche sur master, il n'y a aucun moyen de ne pas inclure ces commits.

S'il n'y a qu'un ou deux commits que vous ne voudriez pas avoir, vous pouvez probablement rebaser de toute façon, et soit le trier dans le conflit de fusion, soit le réparer manuellement, soit simplement annuler le commit. Git a une commande revert qui appliquera les changements opposés, en inversant essentiellement un commit et en le faisant comme si cela ne s'était jamais produit. Pour l'utiliser, exécutez git log pour trouver le commit que vous souhaitez annuler :

Ensuite, copiez le hachage SHA1 et annulez le commit :

git revert 62ee517cc7c358eafbbffdebdde1b38dea92aa0f

Cela créera un revert commit sur la branche feature.

Cherry-Picking s'engage sur une autre branche

Le dernier scénario que vous pouvez rencontrer est s'il n'y a que quelques commits de master que vous aimeriez avoir sur feature. Ceci est courant si vous gérez des branches pour différentes versions, car il existe souvent des correctifs et des correctifs qui doivent être appliqués aux anciennes versions du logiciel.

C'est la méthode la plus ennuyeuse pour synchroniser les choses, car si vous ne gardez pas vos branches au moins quelque peu synchronisées, il y a de fortes chances que le commit que vous souhaitez inclure soit incompatible avec l'ancienne branche.

Mais, Git a des outils pour essentiellement copier et coller des commits sur une branche différente. Cette action s'appelle la sélection de cerises, car vous récupérez un seul commit de l'historique et le retirez. De la même manière que le rebasage, la sélection de cerises crée de nouveaux commits copiés, mais Git est généralement assez intelligent pour le trier, même si vous deviez fusionner les branches ensemble plus tard.

Pour choisir, vous devrez saisir l'ID de validation. Si l'historique de votre branche est compliqué, vous pouvez exécuter git log avec l'option --graph pour obtenir une représentation visuelle de votre historique, bien qu'un client graphique soit particulièrement utile pour les tâches comme ça.

git log --pretty=format:"%h %s" --graph

Ensuite, assurez-vous que vous êtes sur la branche feature et exécutez cherry-pick avec l'ID de validation pour le copier.

git checkout feature
git cherry-pick 1da76d3

Cela peut entraîner des conflits, que vous devrez résoudre.