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 fourches à court terme appelées “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 des branches différentes ?
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 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 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.
Dans la plupart des cas, cependant, vous devriez rechercher des alternatives à devoir séparer les 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 existe essentiellement deux options pour 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.
Publicité
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 principale à un point spécifique, la base de la branche.
Le rebasage consiste essentiellement à soulever toute la branche de fonctionnalité 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 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 identifiants 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 à l'emplacement correct.
Rebaser une branche est assez facile. Vous devrez extraire la branche de fonctionnalité, extraire toutes les modifications de votre télécommande, puis exécuter rebase <branch> pour déplacer la branche de fonctionnalité sur la branche cible.
git checkout feature git pull git rebase master Publicité
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 Git GUI comme Fork ou GitKraken si vous le pouvez. Cela vous montrera les embranchements et vous aidera à planifier le rebase plus efficacement, et peut même effectuer des rebases interactives.
É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 voulez pas inclure certains commits lorsque vous rebase ? Si vous avez des commits sur votre branche de fonctionnalité que vous souhaitez exclure lors du rebasage sur master, 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érez ne pas avoir sur votre branche de fonctionnalité. É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 voudriez ne pas avoir, vous pouvez probablement rebase de toute façon, et soit le régler dans le conflit de fusion, le réparer manuellement ou simplement annuler la validation. Git a un “revert” commande qui appliquera les modifications opposées, 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 62ee517cc7c358eafbbffdebdde1b038dea92a> Cela créera un “revert commit” sur la branche de fonctionnalité.
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 du maître que vous aimeriez avoir sur la fonctionnalité. C'est courant si vous maintenez 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 de synchroniser les choses cependant , car si vous ne maintenez 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, car 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 devez 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 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 la fonctionnalité branche et exécutez cherry-pick avec l'ID de validation pour le copier.
git checkout fonctionnalité git cherry-pick 1da76d3 Publicité
Cela peut entraîner des conflits, que vous devrez résoudre.