Comment mettre à jour et maintenir des branches Git distinctes

L’une des fonctionnalités principales de Git est la possibilité de créer plusieurs versions de votre projet. Souvent, ceux-ci sont utilisés pour des forks à court terme appelés « branches de fonctionnalités », qui sont fusionnés dans le maître. 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 complètement 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 séparées que vous gardez actives 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 changements, 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 à tenir les choses à jour.

Cependant, dans la plupart des cas, 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 des plates-formes différentes, 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 est compilé.

Quelle que soit votre raison, il s’agit d’un workflow Git valide que de nombreuses personnes utilisent.

Garder les branches synchronisées avec le rebasage

Il y a essentiellement deux options pour savoir comment procéder. La première et la plus courante méthode 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 sépare de la branche principale master branche à un endroit précis, le base de la succursale.

Le rebasage consiste essentiellement à soulever l’ensemble feature branche, et en la déplaçant vers un nouveau point dans le temps, où la fin de celle-ci pointe vers une autre chaîne de commits. Ceci est particulièrement utile si la branche forkée ne contient que quelques commits, car les conflits de fusion seront alors plus faciles à régler. Dans cet exemple, le rebasage de cette branche incorpore les commits B et C, mais pas D et E, car il n’a pas besoin de rebaser sur le HEAD de la branche.

Cependant, le rebasage 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 pourraient avoir des commits non poussés faisant référence à ces commits supprimés. Le rebasage devra être quelque chose que vous coordonnez avec tous les collaborateurs, et si quelqu’un a des conflits, ils devront le résoudre localement en copiant ces modifications au bon emplacement.

Rebaser une branche est assez facile. Vous devrez vérifier le feature branche, récupérez toutes les modifications de votre télécommande, puis exécutez rebase <branch> pour déplacer le 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 rebase ? Si vous avez des commits sur votre feature branche 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 le master branche que vous préférez ne pas avoir sur votre feature branche. É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 régler dans le conflit de fusion, le corriger manuellement ou simplement annuler le commit. Git a une commande « revert » qui appliquera les modifications opposées, essentiellement en inversant 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 le feature branche.

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. C’est courant si vous gérez des branches pour différentes versions, car il y a 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, parce que vous récupérez un seul commit de l’historique et le retirez. De la même manière que le rebasage, le cherry-picking crée de nouveaux commits copiés, mais Git est généralement assez intelligent pour les trier, même si vous deviez fusionner les branches plus tard.

Pour choisir, vous devrez récupérer l’ID de validation. Si l’historique de votre branche est compliqué, vous pouvez exécuter git log avec le --graph option pour obtenir une représentation visuelle de votre historique, bien qu’un client GUI soit particulièrement utile pour des tâches comme celle-ci.

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

Ensuite, assurez-vous que vous êtes sur le feature branche 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.