Fourches
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Les duplications (fork) de référentiel Git sont utiles lorsque les utilisateurs souhaitent apporter des modifications expérimentales, risquées ou confidentielles à un codebase, mais ces modifications doivent être isolées du codebase dans le référentiel d’origine. Un nouveau fork est en fait un nouveau référentiel distant qui partage le code source du référentiel d'origine.
En tant que version indépendante, les modifications que vous apportez à votre fork, comme l'ajout de commits ou de branches, sont cachées au référentiel original. Si vous souhaitez fusionner vos modifications codebase dans le référentiel d’origine, vous devez créer une demande de tirage (PR) pour demander la révision et l’approbation de ces modifications.
Le processus de duplication (fork) ne transfère pas d’autorisations, de stratégies ou de pipelines de build du référentiel d’origine vers votre duplication.
Cet article traite de l’utilisation des duplications (fork) dans des référentiels Git Azure Repos et fournit des liens vers du contenu GitHub qui explique comment gérer les duplications dans les référentiels GitHub.
Dans cet article, vous apprendrez comment :
- Partager du code entre des fourches
- Choisir entre des branches et des fourches
- Activez les duplications (fork) de référentiel
- Créer une duplication (fork)
- Cloner votre duplication (fork) localement
- Envoyez (push) des modifications locales à votre duplication (fork)
- Créer et exécuter une demande de tirage
- Synchronisez votre duplication (fork)
Conditions préalables pour l’accès à Azure Repos
Les référentiels doivent être activés dans vos paramètres de projet Azure DevOps. Si le hub Référentiel et les pages associées ne s’affichent pas, consultez Activer ou désactiver un service Azure DevOps pour réactiver le Référentiel.
Pour afficher le code dans des projets privés, vous devez être membre d’un projet Azure DevOps avec un niveau d’accès De base ou supérieur. Pour les projets publics, tout le monde peut afficher le code.
Si vous n’avez pas de projet, créez-en un ou inscrivez-vous gratuitement.
Si vous n’êtes pas membre du projet, soyez ajouté.
Pour cloner ou contribuer au code d’un projet privé, vous devez être membre du groupe de sécurité Contributeurs ou disposer des autorisations correspondantes. Pour les projets publics, n’importe qui peut cloner et contribuer au code. Pour plus d'informations, voir Qu'est-ce qu'un projet public ?
Remarque
Pour les projets publics, les utilisateurs autorisés à accéder aux Parties prenantes ont un accès complet à Azure Repos.
Les référentiels doivent être activés dans vos paramètres de projet Azure DevOps. Si le hub Référentiel et les pages associées ne s’affichent pas, consultez Activer ou désactiver un service Azure DevOps pour réactiver le Référentiel.
Pour afficher le code, vous devez être membre du projet Azure DevOps avec un accès De base ou supérieur. Si vous n’êtes pas membre du projet, soyez ajouté.
Pour cloner ou contribuer au code, vous devez être membre du groupe de sécurité Contributeurs ou disposer des autorisations correspondantes dans le projet que vous souhaitez modifier.
Partager du code entre des fourches
Le référentiel d’origine est souvent appelé référentiel en amont. Vous pouvez créer des demandes de tirage pour fusionner les modifications dans l’une ou l’autre direction : de la duplication (fork) vers l’amont, ou de l’amont vers la duplication. La direction la plus courante est de la duplication (fork) vers l’amont. Les autorisations, stratégies, builds et éléments de travail du référentiel de destination s’appliqueront à la demande de tirage.
Choisir entre des branches et des fourches
Pour une petite équipe de 2 à 5 développeurs, un flux de travail de duplication (fork) peut ne pas être nécessaire, car tout le monde peut travailler dans les branches de fonctionnalités et les stratégies de branche peuvent protéger les branche par défaut. Toutefois, si votre équipe développe et dépasse cette disposition, elle peut basculer vers un flux de travail de duplication (fork).
Si votre référentiel a un grand nombre de validateurs occasionnels ou peu fréquents, comme un projet open source peut le faire, nous vous recommandons le flux de travail de duplication (fork). En règle générale, seuls les contributeurs principaux à votre projet doivent avoir des droits de validation directe sur votre référentiel d’origine. D’autres collaborateurs doivent utiliser un flux de travail de duplication (fork) pour isoler leurs modifications proposées jusqu’à ce que les contributeurs principaux aient la possibilité de passer en revue leur travail.
Activez les duplications (fork) de référentiel
Pour activer les duplications (fork) pour un référentiel Git Azure Repos, consultez Activer les duplications (fork).
Pour activer les duplications (fork) pour un référentiel GitHub, consultez Gestion de la stratégie de duplication pour votre organisation.
Workflow de duplication
Le flux de travail de duplication (fork) se compose de cinq étapes décrites dans les sections suivantes.
- Créer une duplication
- Cloner votre duplication (fork) localement
- Envoyez (push) des modifications locales à votre duplication (fork)
- Créer et exécuter une demande de tirage
- Synchronisez votre duplication (fork)
Créer une duplication (fork)
Les étapes suivantes décrivent comment dupliquer (fork) un référentiel Git Azure Repos.
Remarque
Pour dupliquer (fork) un référentiel dans un projet Azure DevOps, vous devez disposer de l’autorisation de Créer un référentiel pour ce projet. Les propriétaires de référentiels doivent envisager de créer un projet dédié pour les duplications (fork) et d’attribuer l’autorisation Créer un référentiel à tous les contributeurs. Pour plus d’informations sur le paramétrage des autorisations, consultez Définir les autorisations de référentiel Git.
À partir de votre navigateur web, accédez au référentiel Git Azure Repos que vous souhaitez dupliquer (fork). Sélectionnez Référentiel > Fichiers, puis choisissez Duplication (fork) dans le menu de points de suspension pour ouvrir la boîte de dialogue Duplication.
Dans la boîte de dialogue Duplication (fork), nommez le référentiel dupliqué, choisissez le projet dans lequel vous souhaitez créer la duplication, sélectionnez les branches à inclure dans la duplication, puis choisissez Duplication. Vous pouvez spécifier si la duplication (fork) contiendra toutes les branches ou uniquement les branche par défaut. Si le référentiel contient plusieurs branches de rubrique, envisagez d’inclure uniquement les branche par défaut dans votre duplication (fork).
Pour plus d’informations sur la duplication (fork) d’un référentiel GitHub, consultez Dupliquer un référentiel.
Cloner votre duplication (fork) localement
Une fois que vous avez dupliqué (fork) un référentiel, clonez votre duplication pour créer une copie locale dans un dossier sur votre ordinateur. Vous pouvez cloner à partir de la ligne de commande ou à l’aide d’un IDE comme Visual Studio. Pour plus d’informations sur le clonage d’un référentiel, consultez Cloner un référentiel Git existant.
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é. Pour des raisons pratiques, ajoutez un autre alias nommé upstream pour le référentiel à partir duquel vous avez effectué la duplication (fork), appelé référentiel en amont. Les étapes suivantes décrivent comment ajouter un alias upstream.
Conseil
Pour des raisons pratiques, vous pouvez utiliser les alias origin et upstream au lieu de leurs URL correspondantes dans vos commandes Git.
Pour ajouter un alias upstream dans Visual Studio, procédez comme suit :
Choisissez Outils >Options depuis la barre de menus pour ouvrir la fenêtre Options. Sélectionnez Contrôle de code source > Paramètres du référentiel Git > Dépôts distants, puis choisissez Ajouter pour ouvrir la boîte de dialogue Ajouter des dépôts distants.
Dans la boîte de dialogue Ajouter des dépôts distants, ajoutez un nouveau dépôt distant appelé
upstreamet insérez l’URL du clone Git du référentiel dupliqué. Choisissez ensuite Enregistrer.
Envoyez (push) des modifications locales à votre duplication (fork)
Lorsque vous faites un fork, vous créez une version personnelle du référentiel original (le référentiel original est appelé « upstream »). La fourche est indépendante de l'amont, mais elle partage le code et conserve un lien avec l'amont, ce qui permet une synchronisation future. Par conséquent, rien ne vous empêche de travailler directement dans la branche main du clone local, puis d’envoyer (push) ce travail à la branche main de votre duplication (fork). Toutefois, il est généralement préférable d’utiliser des branches de fonctionnalités pour votre travail. À l’aide de branches de fonctionnalités :
Vous pouvez gérer simultanément plusieurs flux de travail indépendants.
Vous facilitez la compréhension du travail que vous partagez par d’autres personnes, car ce travail est organisé en flux de travail distincts par branche.
Un flux de travail Git typique comprend les étapes suivantes :
Créez une branche locale de fonctionnalités ou de corrections de bogues.
Apportez des modifications dans la nouvelle branche et validez votre travail. En règle générale, les utilisateurs effectuent plusieurs validations lorsqu’ils travaillent sur une fonctionnalité ou un correctif de bogue.
Envoyez la branche des fonctionnalités ou des corrections de bogues à votre duplication (fork). Votre duplication a l’alias
origin.
Pour plus d’informations sur la façon d’envoyer (push) vos modifications, consultez Partager du code avec l’envoi (push).
Créer et exécuter une demande de tirage
Dans Azure Repos, pour fusionner dans le référentiel d’origine les modifications que vous avez envoyées (push) vers votre duplication (fork), vous pouvez :
Créez une demande de tirage pour demander l’examen et l’approbation de vos modifications. Lorsque vous ouvrez une demande de tirage, définissez la branche source de demande de tirage sur la fonctionnalité ou la branche de correction de bogue dans votre duplication (fork). La branche cible de demande de tirage est généralement la branche
maindu référentiel que vous avez dupliqué. Ce référentiel est appelé référentiel en amont et possède l’aliasupstream.La capture d’écran suivante montre le référentiel source et la branche et le référentiel cible d’une demande de tirage créée dans Azure Repos.
Pour plus d’informations sur la création d’une demande de tirage à l’aide de votre navigateur, de Visual Studio ou de l’interface CLI Azure DevOps, consultez Créer une demande de tirage.
Important
Toute personne disposant de l’autorisation Lecture sur le référentiel en amont peut y ouvrir une demande de tirage. Si le référentiel en amont a un pipeline de build de demande de tirage configuré pour s’exécuter lors de la création de la demande de tirage, une build s’exécutera sur les modifications introduites par votre demande de tirage.
Pour que votre demande de tirage se termine, tous les réviseurs requis doivent approuver les modifications apportées à la demande de tirage et toutes les stratégies de branche cible doivent être respectées. Lors de l’approbation et de l’achèvement de la demande de tirage, les modifications apportées à la branche source de demande de tirage fusionneront dans la branche cible de demande de tirage.
Pour plus d’informations sur la création et la réalisation d’une demande de tirage GitHub, consultez Création d’une demande de tirage et Fusion d’une demande de tirage.
Synchronisez votre duplication (fork)
Une fois qu’une demande de tirage a fusionné les modifications de votre duplication (fork) dans la branche cible du référentiel en amont, vous pouvez tirer (pull) de la branche cible du référentiel en amont pour mettre à jour votre branche locale correspondante avec vos modifications et toutes les modifications apportées par d’autres contributeurs. Vous êtes alors prêt à :
Créer une nouvelle fonctionnalité ou une branche de correction de bogue à partir de la branche locale mise à jour.
Mettre à jour votre duplication (fork) en effectuant un envoi (push) de votre branche locale mise à jour vers
origin.
En règle générale, la branche cible du référentiel en amont est main. Si vous ne modifiez pas directement votre branche locale main (vous travaillez dans des branches de fonctionnalités), le tirage (pull) à partir de la branche en amont upstream/main mettra à jour votre branche locale main sans conflit de fusion.