Appliquer des modifications avec Rebase

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

Visual Studio 2019 | Visual Studio 2022

Git gère automatiquement un historique de développement sur une branche en liant chaque nouvelle validation à son prédécesseur. Lorsque vous fusionnez une branche dans une autre, l’historique peut devenir moins simple. Par exemple, une fusion sans transfert rapide combine des lignes de développement divergentes en créant une validation de fusion avec plusieurs prédécesseurs. À l’inverse, une base Git combine des lignes de développement divergentes sans créer de validation de fusion, ce qui entraîne une historique de validation plus simple, mais perd des informations sur la fusion. Votre choix de type de fusion est probablement influencé par le fait que vous souhaitez conserver un enregistrement de la fusion ou simplifier l’historique des validations.

Cet article décrit quand utiliser une nouvelle base au lieu d’une fusion sans transfert rapide et fournit des procédures pour les tâches suivantes :

Rebaser votre branche locale
Forcer l’envoi (push) de votre branche locale après une rebase
Rebase interactive pour les validations locales de squash

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

Prerequisites

Catégorie	Spécifications
Accès au projet	Membre d’un projet.
Permissions	- Afficher le code dans des projets privés : accès au moins de base . - Clonez ou contribuez au code dans des projets privés : membre du groupe de sécurité Contributeurs ou autorisations correspondantes dans le projet. - Définir des autorisations de branche ou de référentiel : gérer les autorisations pour la branche ou le référentiel. - Modifier la branche par défaut : modifiez les autorisations des stratégies pour le référentiel. - Importez un référentiel : membre du groupe de sécurité Administrateurs de projet ou de l’autorisation Créer au niveau du projet Git surAutoriser. Pour plus d'informations, voir Définir les autorisations de référentiel Git.
Services	Dépôts activés.
Outils	Optional. Utilisez les commandes az repos : Azure DevOps CLI.

Note

Dans les projets publics, les utilisateurs disposant d’un accès aux parties prenantes ont un accès complet à Azure Repos, notamment l’affichage, le clonage et la contribution au code.

Catégorie	Spécifications
Accès au projet	Membre d’un projet.
Permissions	- Afficher le code : Accès de base au moins. - Cloner ou contribuer au code : membre du groupe de sécurité Contributeurs ou autorisations correspondantes dans le projet.
Services	Dépôts activés.

Rebaser 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. Pour la comparaison, git rebase et d’autres types de fusion sont présentés dans le diagramme suivant.

Diagramme montrant les validations avant et après lors de l’utilisation de Git rebase.

Git rebase resequence l’historique des validations de la branche cible afin qu’elle contienne toutes les validations de branche source, suivie de toutes les validations de branche cible depuis la dernière validation commune. Une autre façon de le voir est qu’une rebase relecture les modifications de votre branche cible en haut de l’historique de branche source. Notamment, Git rebase change 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, le commit K' contient les mêmes modifications que K, mais a un nouvel ID de validation, car il renvoie à la validation E au lieu de C.

Pendant une nouvelle base, si une modification de branche source est en conflit avec une modification de branche cible, Git vous invite à résoudre le conflit de fusion. Vous pouvez résoudre les conflits de fusion lors d’une rebase de la même façon que lors d’une fusion.

Rebaser vs. fusion sans avance rapide

Le rebasing Git entraîne un historique de validation plus simple mais moins exact qu’une fusion sans transfert rapide , autrement appelée fusion à trois voies ou vraies . Lorsque vous souhaitez un enregistrement d’une fusion dans l’historique des validations, utilisez une fusion sans transfert rapide.

Si vous êtes la seule personne travaillant sur une branche de fonctionnalité ou de correctif de bogue, envisagez d’utiliser une rebase pour intégrer régulièrement le travail de branche récente main dans celui-ci. Cette stratégie vous permet de rester au courant du travail récent par d’autres personnes et de résoudre rapidement les conflits de fusion qui se produisent. En rebasing, vous implémentez votre nouvelle fonctionnalité en plus du travail de branche le plus récent main , ce qui permet de conserver un historique de validation linéaire.

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

Rebaser et forcer l’envoi de directives

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

Git rebase et force push sont des outils puissants, mais gardez ces instructions à l’esprit quand vous décidez s’il faut les utiliser :

Ne rebasez pas une branche locale qui a été envoyée (push) et partagée avec d’autres personnes, sauf si vous êtes certain que personne n’utilise la branche partagée. Après une rebase, votre branche locale ne correspond plus à l’historique de son équivalent distant.
Ne forcez pas l’envoi (push) vers une branche distante en cours d’utilisation par d’autres personnes, car leur version locale de la branche distante ne correspond plus à l’historique de branche distante mis à jour.
Votre équipe doit s’entendre sur les scénarios d’utilisation pour le rebasement et la force push.

Conseil / Astuce

Pour un processus de révision collaborative, utilisez une demande de tirage (pull request ) pour fusionner un nouveau travail dans la branche par défaut d’un référentiel distant.

Comment rebaser

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 team Explorer . Pour plus d’informations, consultez l’onglet Visual Studio 2019 - Team Explorer .

Choisissez Git > Manage Branches pour ouvrir la fenêtre Dépôt Git .
Dans la fenêtre Dépôt Git , cliquez avec le bouton droit sur la branche cible, puis sélectionnez Extraction.
Cliquez avec le bouton droit sur la branche source, puis sélectionnez Rebase <target-branch> sur <la branche> source.
Visual Studio affiche un message de confirmation après une nouvelle base réussie.

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

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

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 avertit s’il existe des conflits pendant la rebase. Vous pouvez résoudre les conflits , puis exécuter git rebase --continue, ou git rebase --abort annuler la rebase et revenir à l’état de pré-rebase.

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

Si vous rebasez une branche locale que vous avez envoyée précédemment, un push Git par défaut suivant échoue. Au lieu de cela, vous pouvez forcer l’envoi de votre branche locale pour remplacer son équivalent distant afin que leurs historiques de validation correspondent.

Avertissement

Ne forcez jamais une branche sur laquelle d’autres travaillent. Pour plus d’informations, consultez Rebase et forcez les instructions push.

Pour forcer l’envoi (push) dans Visual Studio, vous devez d’abord activer l’option Force Push :

Accédez aux paramètresglobaux git du> code source>>.
Sélectionnez l’option Activer push --force-with-lease .

L’indicateur Push --force-with-lease Git est plus sûr que l’indicateur --force , car il ne remplacera pas une branche distante qui a des validations qui ne sont pas intégrées dans la branche locale que vous forcez à envoyer ( push).

Dans la fenêtre Modifications Git , sélectionnez le bouton Push pour pousser votre validation.

Vous pouvez également sélectionner Push dans le menu Git .
Si l’opération Push Git par défaut échoue, Visual Studio lance la boîte de dialogue Git-Push échec . Choisissez Force Push.
Visual Studio affiche un message de confirmation après un envoi push réussi.

Conseil / Astuce

Pour forcer l’envoi de nouvelles validations de votre branche locale vers une branche distante nommée identique :

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 push forcée vers :

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

Lorsque vous clonez un référentiel distant, Git attribue l’alias origin comme 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’alias origin . Pour ajouter l’alias origin manuellement, exécutez git remote add origin <remote repo url>. Avec l’alias origin , vous pouvez simplifier davantage la commande push de force :

git push --force-with-lease origin

Si votre branche locale actuelle effectue le suivi d’une branche distante sur origin, vous pouvez entièrement abrégér la commande Force Push :

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 l’état suivi de vos branches.

Rebase interactive pour les validations locales de squash

En règle générale, lorsque vous travaillez sur une nouvelle fonctionnalité dans votre branche de fonctionnalité locale, vous allez créer plusieurs validations. Lorsque vous êtes prêt à publier la nouvelle fonctionnalité, vous souhaiterez peut-être consolider ces validations en une seule validation pour simplifier l’historique des validations. Vous pouvez utiliser une rebase interactive pour écraser plusieurs validations en une seule validation.

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

Consultez la branche locale sur laquelle vous souhaitez effectuer une nouvelle base interactive.
Commit, stash ou ignorez les modifications non validées.
Estimez la distance dans l’historique des validations que vous souhaitez atteindre. Vous n’avez pas besoin d’être exact, car vous aurez à sélectionner des validations spécifiques à squash lorsque vous exécutez la commande de base interactive. Par exemple, si vous souhaitez courguer les validations au cours des cinq dernières validations, exécutez :
```
git rebase -i HEAD~5
```
Git ouvre un éditeur qui répertorie les cinq derniers commits, en commençant par le plus récent. 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
```
Laissez la première ligne comme c’est le cas. Sur les lignes suivantes, pour fusionner une validation avec celle ci-dessus, passez pick à squash. Par exemple, pour combiner les deux principales validations et les deux validations inférieures, modifiez la liste de validations pour :
```
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
```
Enregistrez et fermez l’éditeur. Git ouvre ensuite un nouvel éditeur pour chaque ensemble de validations fusionnées, vous invitant à entrer un message de validation. Pour chaque jeu de validations, condensez les messages de validation jusqu’à un message, 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
```
Même si la validation Fix fiber optic transmitter test n’a pas été écrasée, elle a un nouvel ID de validation, car il lie maintenant à un autre prédécesseur commit.

Pour plus d’informations sur le rebasing interactif, consultez le mode interactif de base Git.

Note

Les utilisateurs d’Azure DevOps peuvent écraser la fusion pour condenser l’historique de validation d’une branche de rubrique pendant une demande de tirage.

Étapes suivantes

Copier les modifications avec cherry-pick

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-12-17