Implémenter le workflow de duplication

Un fork est une copie d’un référentiel. La duplication d’un référentiel vous permet d’expérimenter librement les modifications sans affecter le projet d’origine.

La plupart du temps, les bifurcations sont utilisées pour proposer des modifications à un projet existant ou utiliser un projet existant comme point de départ pour votre idée.

Une fourche est une copie complète d’un dépôt et inclut notamment tous les fichiers, toutes les validations et (éventuellement) toutes les branches.

Les forks sont un excellent moyen de soutenir un flux de travail Inner Source : vous pouvez créer un fork pour suggérer des modifications lorsque vous n'avez pas la permission d'écrire directement dans le projet original. Quand vous êtes prêt à partager ces modifications, vous pouvez le faire facilement à l’aide de demandes de tirage.

Que contient une fourche ?

Au départ, une fourche inclut tout le contenu du dépôt en amont (d’origine) correspondant. Vous pouvez inclure toutes les branches ou les limiter uniquement à la branche par défaut lorsque vous créez une duplication.

Remarques importantes :

• Aucune des autorisations, stratégies ou pipelines de build n’est copiée.
• Le nouveau fork agit comme si quelqu’un a cloné le référentiel d’origine, puis l’a envoyé vers un nouveau référentiel vide.
• Une fois qu’un fork a été créé, les nouveaux fichiers, dossiers et branches ne sont pas partagés entre les référentiels, sauf si une pull request les inclut.

Partager du code entre des fourches

Vous pouvez créer des demandes de tirage dans les deux sens : de la duplication vers l’amont et inversement. Le sens de la duplication (fork) vers l’amont est l’approche la plus courante.

Les autorisations, stratégies, builds et éléments de travail du référentiel de destination s'appliqueront à la pull request.

Choix entre les branches et les fourches

• Small Teams (2 à 5 développeurs) : nous vous recommandons de travailler dans un référentiel unique. Tout le monde doit travailler dans une branche thématique et la branche principale doit être protégée par des politiques de branche.

• Équipes plus grandes : à mesure que votre équipe se développe, vous pouvez vous retrouver dépassé par cette configuration. Dans ce cas, il est préférable de passer à un workflow de duplication.

• Quand utiliser des fourches :

  • Votre référentiel a de nombreux contributeurs occasionnels ou peu fréquents (comme un projet open source).
  • Seuls les contributeurs principaux ont des droits de validation directe dans votre référentiel.
  • Vous souhaitez que les collaborateurs extérieurs à l’équipe principale travaillent à partir d’une duplication (fork).
  • Vous souhaitez isoler les modifications jusqu’à ce que vous ayez eu la chance de passer en revue le travail.

Workflow de duplication

Voici les étapes de base du flux de travail de duplication :

1. Vous créez une fourche.
2. Clonez-le localement.
3. Apportez vos modifications localement et envoyez-les à une branche.
4. Créez et complétez une pull request en amont.
5. Vous synchronisez la fourche avec la dernière version à partir du dépôt en amont.

Étape 1 : Créer le fork

1. Accédez au référentiel que vous souhaitez dupliquer, puis choisissez Dupliquer (fork).
2. Spécifiez un nom et choisissez le projet où créer la bifurcation.
3. Si le référentiel contient de nombreuses branches thématiques, nous vous recommandons de dupliquer uniquement la branche par défaut.
4. Sélectionnez les points de suspension, puis Dupliquer (fork) pour créer la duplication.

Étape 2 : Cloner votre fourche localement

Une fois votre fork prêt, clonez-le à l'aide de la commande ou d'un IDE comme Visual Studio. La fourche sera votre dépôt distant d’origine.

git clone {your_fork_url}
For convenience, after cloning, you'll want to add the upstream repository (where you forked from) as a remote named upstream:

```bash
git remote add upstream {upstream_url}

Étape 3 : Apporter et pousser des modifications

Il est possible de travailler directement dans la branche primaire. En effet, cette fourche est votre copie du dépôt. Toutefois, nous vous recommandons de continuer à travailler dans une branche thématique, car :

• Il vous permet de gérer plusieurs flux de travail indépendants en même temps.
• Cela réduit la confusion plus tard lorsque vous souhaitez synchroniser les modifications dans votre fourche.

Apportez et validez vos modifications comme vous le feriez normalement. Quand vous avez terminé les modifications, envoyez-les vers l’origine (votre fourche).

Étape 4 : Créer et compléter une pull request

Ouvrez une pull request depuis votre fork vers le référentiel en amont. Toutes les stratégies, tous les réviseurs nécessaires et toutes les builds seront appliqués au dépôt en amont. Une fois que toutes les politiques sont satisfaites, le pull request peut être complété et les modifications deviennent une partie permanente du référentiel upstream.

Étape 5 : Synchroniser votre fork avec la dernière version

Quand votre demande de tirage (pull request) est acceptée en amont, vous devez vous assurer que votre duplication reflète l’état le plus récent du référentiel.

Nous vous recommandons de vous baser de nouveau sur la branche primaire en amont (en supposant qu’il s’agit de la branche de développement primaire) :

git fetch upstream main
git rebase upstream/main
git push origin

Avantages du workflow de duplication

Le flux de travail de duplication vous permet d’isoler les modifications du référentiel principal jusqu’à ce que vous soyez prêt à les intégrer. Lorsque vous êtes prêt, l’intégration du code est aussi simple que d'effectuer une pull request.

Cette approche fournit les éléments suivants :

• Sécurité : les modifications sont isolées jusqu’à ce qu’elles soient examinées.
• Collaboration : plusieurs personnes peuvent travailler simultanément sur différentes fonctionnalités.
• Qualité : toutes les modifications passent par le même processus d’examen.
• Flexibilité : Les contributeurs n’ont pas besoin d’un accès en écriture au référentiel principal.