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 demande de tirage( pull request), vous fusionnez la branche de rubrique dans votre branche par défaut, généralement main. Cette fusion ajoute les validations de la branche de rubrique à votre branche principale et crée une validation de fusion pour rapprocher les conflits entre la branche par défaut et la branche de rubrique. Les commentaires et les discussions dans la demande de tirage donnent plus de contexte pour les modifications apportées dans la branche de rubrique.
L’historique de validation sur votre main branche (ou une autre branche par défaut) ne suit pas une ligne droite, en raison de l’historique des branches de rubrique associée. À 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 : 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. |
Fusion de courge
La fusion de 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. La validation de fusion squash n’a pas de référence à la branche de rubrique. Elle produit une nouvelle validation qui contient toutes les modifications de la branche de rubrique. Nous vous recommandons de supprimer la branche de rubrique pour éviter toute confusion.
Un moyen simple de réfléchir à ceci est que la fusion de squash vous donne uniquement les modifications de fichier, et une fusion régulière vous donne les modifications de fichier et l’historique de validation.
Comment une fusion de courge est-elle utile ?
La fusion de courge conserve vos historiques de branche par défaut propres et faciles à suivre sans exiger de modifications de flux de travail sur 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 à l’aide de fusions de courge. L’historique de validation d’une main branche mise à jour avec les fusions de courge a une validation pour chaque branche fusionnée. Vous pouvez parcourir cet historique pour savoir exactement quand le travail a été effectué.
Considérations relatives à la fusion de courge
La fusion de courge condense l’historique des modifications dans votre branche par défaut. Il est donc important de travailler avec votre équipe pour décider quand fusionner et conserver l’historique de validation complet d’une branche de rubrique. Lors de la fusion de courge, il est recommandé de supprimer la branche source. La suppression de la branche source empêche toute confusion, car la branche de rubrique elle-même n’a pas de validation la fusion dans la branche par défaut.
Effectuer des demandes de tirage avec fusion de courge
Vous pouvez choisir de écraser la fusion lors de la fin d’une demande de tirage dans Azure Repos.
Choisissez Squash commit sous Type de fusion dans la boîte de dialogue Terminer la demande de tirage pour fusionner la branche de rubrique.
Bases de fusion multiples
L’onglet Fichiers d’une demande de tirage détecte les différences par une comparaison à trois côtés. 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 y a 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 demande de tirage. Lorsqu’ils sont détectés, Azure DevOps affiche le message « Plusieurs bases de fusion détectées. La liste des validations affichées peut être incomplète » pour la demande de tirage. 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 d’une révision de demande de tirage, assurez-vous que plusieurs bases de fusion ne sont pas la cause racine.
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 à deux autres (signalée par Azure DevOps, mais pas par
git merge-basecela élimine la base de fusion 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- La gestion des conséquences de la branche principale rétablit, par exemple, modifier la validation 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
- D’autres manipulations non intuitives et involontaires avec des restaurations, des sélections de cerises et des fusions
La détection de base de fusion multiple fait partie de la 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 demande de tirage ont des versions différentes entre les bases de fusion, un avertissement de base de fusion multiple 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 demande de tirage sont déjà dans la branche cible, elles sont affichées sous l’onglet Fichiers , mais elles peuvent ne pas déclencher de stratégies de branche mappées aux modifications de dossier.
- Deux ensembles de modifications apportées aux mêmes fichiers à partir de plusieurs bases de fusion peuvent ne pas être 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 cible ou en fusionnant la 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 et à annuler votre progression avant de rebasing ou de fusion. 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 transmission de force à distance si vos modifications sont déjà présentes.
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és à partir des dernières versions de la branche principale 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 dépôts volumineux avec de nombreux contributeurs actifs, ce problème peut être particulièrement gênant. Même si vous vous débarrasser de plusieurs bases par 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 stratégies de génération et les tests sont en cours d’exécution, vous n’avez aucun moyen de terminer la demande de tirage. La réinitialisation et le démarrage d’une nouvelle branche peuvent vous aider. Si rien n’est changé, vos changements sont probablement clairs, même si la situation se répète.