Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Lorsque vous effectuez une pull request, vous fusionnez la branche de sujet dans votre branche par défaut, généralement main. Cette fusion ajoute les commits de la branche thématique à votre branche principale et crée un commit de fusion pour résoudre les conflits entre la branche par défaut et la branche thématique. Les commentaires et les discussions dans la pull request fournissent davantage de contexte sur les modifications apportées dans la branche de rubrique.
L’historique de validation sur votre main branche (ou une autre branche par défaut) n'est pas linéaire, du fait de l’historique des branches de sujet associées. À mesure qu’un projet augmente, le nombre de branches de rubriques travaillées en même temps augmente, ce qui rend l’historique des branches par défaut de plus en plus difficile à suivre.
La branche par défaut est une représentation précise de l’historique de chaque branche de rubrique, mais il est difficile d’utiliser pour répondre à des questions plus larges sur le développement de votre projet.
Prerequisites
| Catégorie | Spécifications |
|---|---|
| Accès au projet | Membre d’un projet. |
| Permissions | - Afficher le code dans des projets privés : au moins un accès niveau 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. - Définissez des stratégies de branche, des contrôles d’état ou modifiez la branche par défaut : autorisation Modifier les stratégies pour le référentiel ou la branche, ou appartenance au groupe de sécurité Administrateurs du projet. - Importez un référentiel : membre du groupe de sécurité Administrateurs de projet ou détenteur de l’autorisation Créer un référentiel au niveau du projet Git avec la permission Autoriser. Pour plus d'informations, voir Définir les autorisations de référentiel Git. |
| Services | Dépôts activés. |
| Outils | Optional. Utilisez az repos : Azure DevOps CLI. |
| Catégorie | Spécifications |
|---|---|
| Accès au projet | Membre d’un projet. |
| Permissions | - Afficher le code : accès basique minimum. - Cloner ou contribuer au code : membre du groupe de sécurité Contributeurs ou autorisations correspondantes dans le projet. |
| Services | Dépôts activés. |
Fusion Squash
La fusion Squash est une option de fusion qui vous permet de condenser l’historique Git des branches de rubrique lorsque vous effectuez une demande de tirage. Au lieu d’ajouter chaque validation sur la branche de rubrique à l’historique de la branche par défaut, une fusion squash ajoute toutes les modifications de fichier à une nouvelle validation unique sur la branche par défaut. Le commit de fusion Squash ne dispose pas de référence à la branche de rubrique. Elle produit une nouvelle validation comprenant toutes les modifications de la branche thématique. Nous vous recommandons de supprimer la branche de rubrique pour éviter toute confusion.
Un moyen simple de réfléchir à ceci est qu'une fusion squash vous donne uniquement des modifications de fichier, tandis qu'une fusion régulière vous donne des modifications de fichier ainsi que l'historique de commits.
En quoi une fusion Squash est-elle utile ?
La fusion Squash maintient vos historiques branche par défaut propres et faciles à suivre sans exiger de modifications de workflow pour votre équipe. Les contributeurs à la branche de rubrique fonctionnent comme ils le souhaitent dans la branche de rubrique, et les branches par défaut conservent un historique linéaire grâce à l’utilisation de fusions Squash. L’historique de commit d’une main branche mise à jour avec fusions Squash comporte un commit pour chaque branche fusionnée. Vous pouvez parcourir cet historique pour savoir exactement quand le travail a été effectué.
Considérations relatives à la fusion avec squash
La fusion Squash condense l’historique des modifications dans votre branche par défaut. Il est donc important de travailler avec votre équipe pour décider quand faire une fusion Squash ou quand conserver l’historique de commit complet d’une branche de rubrique. Lors d’une fusion Squash, il est recommandé de supprimer la branche source. La suppression de la branche source évite toute confusion, car la branche de sujet elle-même n’a pas de commit la fusionnant dans la branche par défaut.
Effectuer des demandes de tirage avec fusion Squash
Vous pouvez choisir de faire une fusion Squash lors de la fin d’une demande de tirage dans Azure Repos.
Choisissez Commit Squash sous Type de fusion dans la boîte de dialogue Terminer la demande de tirage pour faire une fusion Squash de la branche de rubrique.
Bases de fusion multiples
L’onglet Fichiers d’un pull request identifie les différences par une comparaison à trois volets. L’algorithme prend en compte la dernière validation dans la branche cible, la dernière validation dans la branche source et leur base de fusion commune, par exemple, le meilleur ancêtre commun. L’algorithme est une méthode rapide, économique et fiable de détection des modifications. Malheureusement, dans certains cas, il existe plusieurs bases vraies. Dans la plupart des référentiels, cette situation est rare, mais dans les référentiels volumineux avec de nombreux utilisateurs actifs, il peut être courant. Vous pouvez vérifier manuellement si plusieurs bases de fusion entre les branches existent. Pour ce faire, exécutez la git merge-base --all feature master commande. Azure DevOps détecte l'existence de plusieurs bases de fusion pour chaque PR. Lorsqu’ils sont détectés, Azure DevOps affiche le message « Plusieurs bases de fusion détectées. La liste des commits affichée peut être incomplète » pour le PR. Bien qu’Azure DevOps exécute la détection de plusieurs bases de fusion, il ne vérifie pas si la base de fusion potentielle a déjà été fusionnée ou non. Cette vérification est effectuée par git merge-base. C’est pourquoi Azure DevOps peut afficher le message même quand git merge-base il ne signale qu’une seule base de fusion.
Note
Si vous avez perdu des modifications lors de la révision d'un PR, assurez-vous que la cause principale n'est pas la présence de plusieurs bases de fusion.
Les exemples de scénarios suivants sont détectés par Azure DevOps comme plusieurs bases, avec les bases de fusion indiquées par les nombres 1 et deux :
- Fusions croisées (également appelées criss-cross) entre différentes branches (signalées par Azure DevOps et
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Fusion d'une branche vers les deux autres (signalé par Azure DevOps, mais pas par
git merge-basequi élimine la base de fusion 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Traitement des séquelles des reverts de la branche principale, par exemple modifier le commit de fusion.
* 42bb2d2 (HEAD, A) Amended merge commit
|\
| | * 67c9bb8 (other) Merge branch 'A' into B
| | |\
| |/ /
|/| /
| |/
| * fa78e32 add second commit
* | 15845c9 add first commit
|/
* 6a52130 add init
- Réutilisation active des branches de fonctionnalités
- Autres manipulations non intuitives et compliquées avec des restaurations, des cherry-pick et des fusions
La détection de bases de fusion multiples fait partie des pratiques de sensibilisation à la sécurité. S’il existe plusieurs bases de fusion, l’algorithme de différence de fichier pour l’interface utilisateur risque de ne pas détecter correctement les modifications de fichier, selon la base de fusion choisie. Si les fichiers de la pull request ont des versions différentes entre les bases de fusion, un avertissement de bases de fusion multiples se produit.
Pour plus d’informations, consultez la documentation git officielle .
Risques de sécurité potentiels de la fusion à partir de plusieurs bases
- Un utilisateur malveillant peut abuser de l’algorithme d’interface utilisateur pour valider des modifications malveillantes qui ne sont pas présentes dans la demande de tirage.
- Si les modifications proposées dans la pull request (PR) sont déjà dans la branche cible, elles sont affichées sous l’onglet Fichiers, mais elles peuvent ne pas déclencher les politiques de branche qui sont mappées aux modifications de dossier.
- Il se peut que deux ensembles de modifications apportées aux mêmes fichiers à partir de plusieurs bases de fusion ne soient pas présents dans la demande de tirage. Ce cas peut créer des lacunes logiques perfides.
Comment résoudre le problème de plusieurs bases de fusion
La présence de plusieurs bases de fusion n’est pas nécessairement mauvaise, mais vous devez vérifier que tout est correct. Pour vous débarrasser de plusieurs bases de fusion, attachez les branches à un ancêtre commun unique en rebasant votre branche sur la branche cible ou en fusionnant la branche cible dans votre branche. Ces actions se débarrassent du message d’avertissement et vous aident à vérifier si les modifications réelles sont correctes.
L’une des approches consiste à réinitialiser de manière réversible et à cacher votre progression avant de rebaser ou de fusionner. Vous pouvez ensuite créer une branche ou rebaser une branche vide et appliquer vos modifications à partir d’un point clair. Ce processus peut nécessiter une poussée forcée à distance si vos modifications sont déjà là.
Comment éviter le problème de plusieurs bases de fusion
Voici des conseils généraux pour éviter le problème de base de fusion multiple :
- Lors de la préparation d’une demande de tirage, créez des branches de fonctionnalité à partir des dernières versions de la branche primaire ou release.
- Évitez de créer des branches qui ne proviennent pas directement des branches stables de votre référentiel, sauf si nécessaire.
Que faire si le problème de plusieurs bases de fusion réapparaît
Dans les grands référentiels avec de nombreux contributeurs actifs, ce problème peut être particulièrement gênant. Même si vous vous débarrassez de plusieurs bases par un processus de fusion, la situation peut réapparaître. Si quelqu’un ferme une demande de tirage de longue date, cela peut recréer la situation. Même si les politiques de build et les tests sont en cours d’exécution, vous n’avez aucun moyen de finaliser la pull request. La réinitialisation et le démarrage d’une nouvelle branche peuvent aider. Si rien n’est changé, vos changements sont probablement clairs, même si la situation se répète.