Workflow de duplication (fork)

1. Un développeur effectue un « fork » d'un dépôt « officiel » côté serveur. Cette opération crée sa propre copie côté serveur.

2. La nouvelle copie côté serveur est clonée dans son système local.

3. Un chemin Git distant pour le dépôt « officiel » est ajouté au clone local.

4. Une nouvelle branche de fonctionnalité locale est créée.

5. Le développeur apporte des changements sur la nouvelle branche.

6. De nouveaux commits sont créés pour les changements.

7. La branche est pushée vers la copie côté serveur du développeur.

8. Le développeur ouvre une pull request depuis la nouvelle branche vers le dépôt « officiel ».

9. Le merge de la pull request est approuvé et cette dernière est mergée dans un dépôt côté serveur d'origine.

Afin d'intégrer la fonctionnalité dans la base de code officielle, le mainteneur de projet récupère les changements apportés par le contributeur dans le dépôt local, veille à ne pas scinder le projet, en fait un merge dans sa branche principale (main) locale, puis pushe la branche main vers le dépôt officiel sur le serveur. La contribution fait désormais partie intégrante du projet, et les autres développeurs devraient extraire des éléments du dépôt officiel pour synchroniser leurs dépôts locaux.

Il est important de comprendre que la notion de dépôt « officiel » dans un workflow de duplication (fork) n'est qu'une simple convention. En réalité, la seule caractéristique qui rend le dépôt officiel si officiel est qu'il est le dépôt public du mainteneur de projet.

Il est important de noter que les dépôts « forkés » et le « forking » ne sont pas des opérations spéciales. Les dépôts forkés sont créés à l'aide de la commande git clone standard. Les dépôts forkés sont généralement des « clones côté serveur ». En principe, ils sont gérés et hébergés par un service Git tiers comme Bitbucket. Il n'existe aucune commande Git unique pour créer des dépôts forkés. Une opération de clonage est essentiellement une copie d'un dépôt et son historique.

Tous ces dépôts publics personnels simplifient réellement le partage des branches avec d'autres développeurs. Tout le monde doit continuer d'utiliser des branches pour isoler les fonctionnalités individuelles, tout comme dans le workflow de branche de fonctionnalité et le workflow Gitflow. La seule différence est la manière dont ces branches sont partagées. Dans le workflow de duplication (fork), elles sont incluses au dépôt local d'un autre développeur, tandis que dans le workflow de branche de fonctionnalité et le workflow Gitflow, elles sont pushées vers le dépôt officiel.

Tous les nouveaux développeurs dans un projet de workflow de duplication doivent forker le dépôt officiel. Comme indiqué au préalable, la duplication (fork) n'est qu'une opération git clone standard. Pour ce faire, ils doivent établir une connexion SSH avec le serveur et exécuter git clone pour le copier à un autre emplacement du serveur. Les services d'hébergement Git populaires, comme Bitbucket, fournissent des fonctionnalités de duplication de dépôts qui automatisent cette étape.

Tous les nouveaux développeurs dans un projet de workflow de duplication doivent forker le dépôt officiel. Comme indiqué au préalable, la duplication (fork) n'est qu'une opération git clone standard. Pour ce faire, ils doivent établir une connexion SSH avec le serveur et exécuter git clone pour le copier à un autre emplacement du serveur. Les services d'hébergement Git populaires, comme Bitbucket, fournissent des fonctionnalités de duplication de dépôts qui automatisent cette étape.

Supposons que nous utilisions Bitbucket pour héberger ces dépôts. Les développeurs doivent posséder leur propre compte Bitbucket et cloner leur copie forkée du dépôt en utilisant :

Alors que d'autres workflows Git utilisent une seule branche d'origine distante qui pointe vers le dépôt centralisé, le workflow de duplication (fork) nécessite deux branches distantes : une pour le dépôt officiel et l'autre pour le dépôt personnel du développeur côté serveur. Vous pouvez nommer ces branches distantes comme bon vous semble, mais il est d'usage d'employer origin comme branche distante pour votre dépôt forké (il sera créé automatiquement quand vous lancerez git clone) et pour le dépôt officiel.

Vous devrez créer le dépôt distant vous-même en utilisant la commande ci-dessus. Vous pourrez ainsi tenir à jour votre dépôt local à mesure que le projet officiel avancera. Notez que si l'authentification est activée pour votre dépôt distant (celui-ci n'est pas open source), vous devrez indiquer un nom d'utilisateur de la manière suivante :

Par ce biais, les utilisateurs doivent indiquer un mot de passe valide avant de procéder au clonage ou à l'extraction de la base de code officielle.

Dans sa copie locale du dépôt forké, le développeur peut éditer le code, commiter des changements et créer des branches, comme dans n'importe quel workflow Git :

Tous leurs changements seront entièrement privés, jusqu'à ce qu'ils les pushent vers leur dépôt public. De plus, si le projet officiel a avancé, ils peuvent accéder à de nouveaux commits en exécutant git pull :

Dans la mesure où les développeurs doivent travailler dans une branche de fonctionnalité dédiée, cette commande devrait normalement entraîner un fast-forward merge.

Une fois qu'un développeur est prêt à mettre en commun sa nouvelle fonctionnalité, il doit réaliser deux opérations. Premièrement, il doit rendre sa contribution accessible aux autres développeurs en la pushant vers son dépôt public. Sa branche distante origin devrait déjà être créée, donc il ne lui reste plus qu'à lancer la commande suivante :

À la différence des autres workflows, le dépôt distant origin pointe vers le dépôt privé côté serveur du développeur, et non vers la base de code principale.

Deuxièmement, lorsque les développeurs souhaitent merger leurs fonctionnalités dans la base de code officielle, ils doivent en informer le mainteneur de projet. Dans Bitbucket, le bouton « Pull request » renvoie vers un formulaire qui vous demande la branche à merger dans le dépôt officiel. Le plus souvent, vous voudrez intégrer votre branche de fonctionnalité (feature) dans la branche main du dépôt distant en amont.

Pour résumer, le workflow de duplication (fork) est communément utilisé dans des projets open source publics. Le fork est une opération git clone exécutée sur une copie serveur d'un dépôt de projets. Un workflow de duplication (fork) est souvent utilisé conjointement avec un service d'hébergement Git comme Bitbucket. Voici un exemple de niveau élevé de workflow de duplication (fork) :

1. Vous souhaitez contribuer à une bibliothèque open source hébergée sur bitbucket.org/userA/open-project

2. À l'aide de Bitbucket, créez un fork du dépôt à l'adresse bitbucket.org/YourName/open-project

3. Sur votre système local, vous exécutez git clone sur https://bitbucket.org/YourName/open-project pour obtenir une copie locale du dépôt.

4. Vous créez une nouvelle branche de fonctionnalité (feature) dans votre dépôt local.

5. Vous terminez la nouvelle fonctionnalité, et la commande git commit est exécutée pour enregistrer les changements.

6. Vous pushez ensuite la nouvelle branche de fonctionnalité (feature) vers votre dépôt forké distant.

7. Avec Bitbucket, vous ouvrez une pull request pour la nouvelle branche par rapport au dépôt d'origine à l'adresse : bitbucket.org/userA/open-project

Le workflow de duplication (fork) aide le mainteneur d'un projet à ouvrir le dépôt aux contributions de tous les développeurs, sans avoir à gérer manuellement les paramètres d'autorisation pour chaque contributeur individuel. Pour le mainteneur, il s'agit d'un workflow de type « pull ». Principalement utilisé dans les projets open source, le workflow de duplication (fork) peut également être appliqué aux workflows métier privés pour apporter un contrôle sur ce qui est mergé dans une livraison. Cela peut être utile pour les équipes disposant de gestionnaires de déploiement ou de cycles de livraison stricts.

Vous ne savez pas quel workflow choisir ? Consultez notre page complète Comparaison de workflows Git.