Appliquer des modifications avec Rebase

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Git conserve automatiquement un historique de développement sur une branche en reliant chaque nouvelle validation à son prédécesseur. Lorsque vous fusionnez une branche avec une autre, l’historique peut devenir moins simple. Par exemple, une fusion sans avance rapide combine des lignes de développement divergentes en créant une fusion validée avec plusieurs prédécesseurs. À l’inverse, un Git rebase associe des lignes de développement divergentes sans créer de validation de fusion, permettant ainsi de simplifier l’historique de validation, mais entraînant une perte d'informations concernant la fusion. Votre choix de type de fusion est probablement influencé par le fait de vouloir conserver un enregistrement de la fusion ou de simplifier l’historique des validations.

Cet article explique quand utiliser un rebase au lieu d’une fusion sans avance rapide, et fournit des procédures pour les tâches suivantes :

• Rebasez votre branche locale
• Forcer l’envoi (push) de votre branche locale après un rebase
• Rebase interactif pour écraser les validations locales

Pour obtenir une vue d’ensemble du flux de travail Git, consultez le tutoriel Git Azure Repos.

Rebasez votre branche locale

Git rebase intègre les validations d’une branche source dans votre branche locale actuelle (branche cible). La branche source reste inchangée. À des fins de comparaison, Git rebase et d’autres types de fusion sont présentés dans le diagramme suivant.

Git rebase réordonne l’historique des validations de la branche cible de manière à contenir toutes les validations de branche source, suivies de toutes les validations de branche cible depuis la dernière validation commune. Une autre manière de voir ceci est qu'un rebase reproduit les changements dans votre branche cible au-delà de l'historique de la branche source. Notamment, Git rebase modifie la séquence des validations de branche cible existantes, ce qui n’est pas le cas pour les autres stratégies de fusion. Dans le diagramme précédent, la validation K' contient les mêmes modifications que K, mais avec un nouvel ID de validation, puisqu’il renvoie à la validation E au lieu de C.

Lors d’un rebase, si un changement de branche source est en conflit avec un changement de branche cible, Git vous invite à résoudre le conflit de fusion. Vous pouvez résoudre les conflits de fusion pendant un rebase de la même manière que vous résolvez les conflits de fusion durant une fusion.

Rebaser vs Fusion sans avance rapide

Git rebasing génère un historique de validation plus simple, mais moins exact qu’une fusion sans avance rapide, également appelée fusion triple ou vraie . Lorsque vous souhaitez enregistrer une fusion dans l’historique des validations, utilisez une fusion sans avance rapide.

Si vous êtes la seule personne à travailler sur une fonctionnalité ou une branche de correction de bogues, envisagez d’utiliser un rebase pour y intégrer régulièrement le travail de branche récent main. Cette stratégie vous permet de rester informé des travaux récents d’autres utilisateurs et de résoudre rapidement les conflits de fusion pouvant survenir. En rebasant, vous implémentez votre nouvelle fonctionnalité par-dessus le travail de branche le plus récent main, permettant ainsi de conserver un historique de validation linéaire.

Pour plus d’informations sur le Git rebase et quand l’utiliser, consultez Rebase vs fusion.

Recommandations de rebase et d’envoi forcé

Si vous rebasez une branche locale précédemment envoyée, puis que vous réexécutez la commande Push Git par défaut, l’envoi échoue. La commande Push Git par défaut applique une fusion rapide pour intégrer votre branche locale à la branche distante. Cette commande échoue après un rebase, puisque le rebase modifie la séquence de validations existantes dans votre branche cible locale, si bien qu’elle ne correspond plus à l’historique de son équivalent distant. Dans ce scénario, un force push réussit en remplaçant la branche distante.

Git rebase et Force push constituent des outils puissants, mais gardez ces conseils à l’esprit lorsque vous décidez de les utiliser :

• Ne rebasez pas une branche locale envoyée (push) et partagée avec d’autres personnes, à moins que vous soyez certain que personne n’utilise la branche partagée. Après un rebase, votre branche locale ne correspond plus à l’historique de son équivalent distant.
• N’effectuez aucun force push vers une branche distante utilisée par d’autres utilisateurs, puisque leur version locale de la branche distante ne correspond plus à l’historique de branche distante mis à jour.
• Votre équipe doit se mettre d'accord sur les scénarios d'utilisation de rebase et de force push.

Conseil

Pour un processus de révision collaboratif, utilisez une requête de tirage permettant de fusionner un nouveau travail dans le branche par défaut d’un référentiel distant.

Comment procéder à un rebase

Visual Studio 2022

Visual Studio 2022 offre une expérience de contrôle de version Git à l’aide du menu Git, des modifications Git et des menus contextuels dans l’Explorateur de solutions. Visual Studio 2019 version 16.8 offre également l’interface utilisateur Git de Team Explorer. Pour plus d’informations, consultez l’onglet Visual Studio 2019 - Team Explorer.

1. Choisissez Git > Gérer les branches pour ouvrir la fenêtre Référentiel Git .

   

2. Dans la fenêtre Référentiel Git, cliquez avec le bouton droit sur la branche cible, puis sélectionnez Extraction.

   

3. Cliquez avec le bouton droit sur la branche source, puis sélectionnez Rebase <Branche cible> sur <Branche source>.

   

4. Visual Studio affiche un message de confirmation après un rebase réussi.

   

   Si le rebase est arrêté en raison de conflits de fusion, Visual Studio vous en informera. Vous pouvez résoudre les conflits ou annuler le rebase et revenir à l’état de pré-rebase.

   

Visual Studio 2019 - Menu Git

Visual Studio 2019 offre une expérience de contrôle de version Git à l’aide du menu Git, des modifications Git et des menus contextuels dans l’Explorateur de solutions.

1. Choisissez Git > Gérer les branches pour ouvrir la fenêtre Référentiel Git .

   

2. Dans la fenêtre Référentiel Git, cliquez avec le bouton droit sur la branche cible, puis sélectionnez Extraction.

   

3. Cliquez avec le bouton droit sur la branche source, puis sélectionnez Rebase <Branche cible> sur <Branche source>.

   

4. Visual Studio affiche un message de confirmation après un rebase réussi.

   

   Si le rebase est arrêté en raison de conflits de fusion, Visual Studio vous en informera. Vous pouvez résoudre les conflits ou annuler le rebase et revenir à l’état de pré-rebase.

   

Visual Studio 2019 - Team Explorer

Visual Studio 2019 version 16.8 et versions ultérieures fournit une expérience de gestion de version Git tout en conservant l’interface utilisateur Git de Team Explorer. Pour utiliser Team Explorer, décochez Outils>Options>Fonctionnalités en préversion>Nouvelle expérience utilisateur Git dans la barre du menu. Vous pouvez exercer les fonctionnalités Git à partir de l’une ou l’autre interface de manière interchangeable.

1. Dans Team Explorer, sélectionnez Accueil et choisissez Branches.

   

2. Dans la vue Branches, cliquez avec le bouton droit sur la branche cible, puis sélectionnez Extraction.

   

3. Cliquez avec le bouton droit sur la branche source, puis sélectionnez Rebase sur.

   

4. Vérifiez les options de rebase, puis cliquez sur Rebase.

   

5. Visual Studio affiche un message de confirmation après un rebase réussi.

   

   En cas de conflit lors du rebase, Visual Studio vous en informera. Vous pouvez résoudre les conflits ou annuler le rebase et revenir à l’état de pré-rebase.

   

Ligne de commande Git

Pour intégrer des validations de branche source dans une branche cible, exécutez la commande git rebase :

git rebase <source branch name> <target branch name>

Si votre branche locale actuelle est la branche cible, vous pouvez simplifier la commande de rebase sur :

git rebase <source branch name>

Git vous informera des conflits éventuels lors du rebase. Vous pouvez résoudre les conflits, puis exécuter git rebase --continue, ou exécuter git rebase --abort pour annuler le rebase et revenir à l’état de pré-rebase.

Forcer l’envoi (push) de votre branche locale après un rebase

Si vous rebasez une branche locale précédemment envoyée, un push Git par défaut suivant échoue. Au lieu de cela, vous pouvez envoyer (push) votre branche locale pour remplacer son équivalent distant et correspondre les historiques de validation.

Avertissement

N’envoyez (push) jamais une branche sur laquelle d’autres travaillent. Pour plus d’informations, consultez les Instructions de rebase et de force push.

Pour envoyer (push) dans Visual Studio, vous devez tout d’abord activer l’option force push :

1. Accédez à Outils>Options>Contrôle de source>Paramètres globaux Git.

2. Sélectionnez l’option Activer push --force-with-lease .

L’--force-with-leaseindicateur Push Git est plus sûr que l’--forceindicateur, puisqu’il ne remplacera pas une branche distante contenant des validations non-intégrés dans la branche locale que vous forcez à envoyer.

Visual Studio 2022

1. Dans la fenêtre Modifications Git, sélectionnez le bouton push pour envoyer votre validation.

   

   Vous pouvez également sélectionner Push dans le menu Git.

   

2. Si l’opération Git push par défaut échoue, Visual Studio lance la boîte de dialogue Échec de Git-push. Choisissez Force push.

   

3. Visual Studio affiche un message de confirmation à la suite d’un envoi (push) réussi.

   

Visual Studio 2019 - Menu Git

1. Dans la fenêtre Modifications Git, sélectionnez le bouton push pour envoyer votre validation.

   

   Vous pouvez également sélectionner Push dans le menu Git.

   

2. Si l’opération Git push par défaut échoue, Visual Studio lance la boîte de dialogue Échec de Git-push. Choisissez Force push.

   

3. Visual Studio affiche un message de confirmation à la suite d’un envoi (push) réussi.

   

Visual Studio 2019 - Team Explorer

Visual Studio 2019 version 16.8 et versions ultérieures fournit une expérience de gestion de version Git tout en conservant l’interface utilisateur Git de Team Explorer. Pour utiliser Team Explorer, décochez Outils>Options>Fonctionnalités en préversion>Nouvelle expérience utilisateur Git dans la barre du menu. Vous pouvez exercer les fonctionnalités Git à partir de l’une ou l’autre interface de manière interchangeable.

1. Dans Team Explorer, sélectionnez Accueil et choisissez Synchroniser pour ouvrir l’affichage Synchronisation.

   

2. Dans l’affichage Synchronisation, choisissez Envoyer pour charger votre validation dans le référentiel distant.

   

3. Si l’opération Git push par défaut échoue, Visual Studio lance la boîte de dialogue Échec de Git-push. Choisissez Force push.

   

4. Visual Studio affiche un message de confirmation à la suite d’un envoi (push) réussi.

   

Ligne de commande Git

Conseil

L’--force-with-leaseindicateur Push Git est plus sûr que l’--forceindicateur, puisqu’il ne remplacera pas une branche distante contenant des validations non-intégrés dans la branche locale que vous forcez à envoyer.

Pour effectuer un force push sur de nouvelles validations à partir de votre branche locale vers une branche distante nommée :

git push --force-with-lease <remote> <local branch name>

Si la branche que vous souhaitez envoyer (push) est votre branche extraite, vous pouvez simplifier la commande force push pour :

git push --force-with-lease <remote>

Lorsque vous clonez un référentiel distant, Git affecte l’alias origin en tant que raccourci pour l’URL du référentiel distant que vous avez cloné. Exécutez git remote -v pour vérifier la valeur de l’aliasorigin. Pour ajouter l’alias origin manuellement, exécutez git remote add origin <remote repo url>. Avec l’aliasorigin, vous pouvez simplifier davantage la commande Push forcé :

git push --force-with-lease origin

Si votre branche locale actuelle effectue le suivi d’une branche distante sur origin, vous pouvez totalement abréger la commande push forcé :

git push --force-with-lease

Toutefois, la commande Push entièrement abrégée échoue si votre branche locale ne suit pas une branche distante. Exécutez git remote show origin pour vérifier le statut suivi de vos branches.

Rebase interactif pour écraser les validations locales

En règle générale, lorsque vous travaillez sur une nouvelle fonctionnalité au sein de votre branche de fonctionnalité locale, vous créez plusieurs validations. Lorsque vous êtes prêt à publier la nouvelle fonctionnalité, vous pouvez regrouper ces validations en une seule validation pour simplifier l’historique de validation. Vous pouvez utiliser un rebase interactif pour écraser plusieurs validations en une seule validation.

Visual Studio 2022

Visual Studio 2022 ne prend pas en charge le rebase interactif. Utilisez plutôt la ligne de commande Git.

Visual Studio 2019 - Menu Git

Visual Studio 2019 ne prend pas en charge le rebase interactif. Utilisez plutôt la ligne de commande Git.

Visual Studio 2019 - Team Explorer

Visual Studio 2019 ne prend pas en charge le rebase interactif. Utilisez plutôt la ligne de commande Git.

Ligne de commande Git

1. Extrayez la branche locale sur laquelle vous souhaitez effectuer un rebase interactif.

2. Validez, mettez en cache ou ignorez les modifications non validées.

3. Estimez jusqu'où vous souhaitez remonter dans l'historique des livraisons. Vous n’avez pas besoin d’être précis, puisque vous pourrez sélectionner des validations spécifiques pour écraser lors de l’exécution de la commande de rebase interactive. Par exemple, si vous souhaitez écraser les validations des cinq dernières validations, exécutez :

   git rebase -i HEAD~5
   

   Git ouvre un éditeur répertoriant les cinq dernières validations, en commençant par les plus récentes. Par exemple :

   pick 7068b09 Update README network switch section
   pick 9d247f7 Update README network controller section
   pick 5d7ab9f Fix fiber optic transmitter test
   pick 7b43f3f Add network switch test
   pick 00859d9 Add network controller test
   

4. Laissez la première ligne telle quelle. Sur les lignes suivantes, pour fusionner une validation avec celle du dessus, remplacez pick par squash. Par exemple, pour associer les deux validations supérieures et les deux validations inférieures, modifiez la liste de validations comme suit :

   pick 7068b09 Update README network switch section
   squash 9d247f7 Update README network controller section
   pick 5d7ab9f Fix fiber optic transmitter test
   pick 7b43f3f Add network switch test
   squash 00859d9 Add network controller test
   

5. Enregistrez le fichier et fermez l’éditeur. Git ouvre ensuite un nouvel éditeur pour chaque ensemble de validations fusionnées, vous invitant à insérer un message de validation. Pour chaque jeu de validations, condensez les messages de validation en un seul, puis enregistrez et fermez l’éditeur. Dans l’exemple précédent, les validations écrasées sont condensées avec les nouveaux messages de validation :

   8fcb88f Update README network sections
   ac6d3c0 Fix fiber optic transmitter test
   f0aadc3 Add two network tests
   

   Bien que la validation Fix fiber optic transmitter test n’a pas été écrasée, elle présente un nouvel ID de validation, puisqu’elle est désormais reliée à une autre validation antérieure.

Pour plus d’informations sur le rebase interactif, consultez le Mode interactif de rebase Git.

Notes

Les utilisateurs Azure DevOps peuvent écraser la fusion pour comprimer l’historique des validations relatives à une branche de rubrique lors d’une requête de tirage.

Étapes suivantes

Copier des modifications avec cherry-pick

Articles connexes

• Nouveautés dans les référentiels Git ? En savoir plus
• Partager du code avec Push
• Mettez à jour le code à l’aide de la récupération, fusion et extraction