Workflow de duplication (fork)

 

Le workflow de duplication (fork) est fondamentalement différent des autres workflows Git populaires. Au lieu d'utiliser un dépôt unique côté serveur pour agir en tant que base de code « centrale », ce workflow fournit un dépôt côté serveur à chaque développeur. Par conséquent, chaque contributeur dispose non pas d'un, mais de deux dépôts Git : un privé en local et un public côté serveur. Le workflow de duplication (fork) se rencontre principalement dans les projets open source publics.

Le principal avantage du workflow de duplication (fork) est que les contributions peuvent être intégrées sans l'intervention d'une autre personne pour les pusher vers un dépôt centralisé unique. Les développeurs font un push vers leurs propres dépôts côté serveur, et seul le mainteneur de projet peut pusher vers le dépôt officiel. Le mainteneur peut ainsi accepter les commits de n'importe quel développeur sans accorder un accès en écriture à la base de code officielle.

Le workflow de duplication (fork) suit généralement un modèle de création de branches basé sur le workflow Gitflow. Cela signifie que des branches de fonctionnalité complètes seront proposées pour un merge dans le dépôt du mainteneur du projet initial. Résultat : un workflow distribué qui permet aux grandes équipes et aux équipes organiques (y compris les tiers non approuvés) de collaborer de façon flexible et en toute sécurité. Le workflow obtenu est aussi idéal pour les projets open source.
 

Fonctionnement

Comme dans les autres workflows Git, le workflow de duplication (fork) démarre par un dépôt public officiel stocké sur un serveur. Lorsqu'un nouveau développeur veut commencer à travailler sur le projet, il ne clone pas directement le dépôt officiel.

À la place, ils font un fork du dépôt officiel pour en créer une copie sur le serveur. Celle-ci leur servira de dépôt public personnel : aucun autre développeur ne sera autorisé à pusher des éléments vers celui-ci, mais ils pourront y récupérer des changements (nous verrons dans un instant pourquoi c'est important). Après avoir créé sa copie côté serveur, le développeur lance git clone pour la copier sur sa machine locale. Celle-ci constitue son environnement de développement privé, comme dans les autres workflows.

Lorsqu'il est prêt à publier un commit local, il pushe le commit vers son propre dépôt public, pas vers le dépôt officiel. Ensuite, il fait une pull request avec le dépôt principal, ce qui permet au mainteneur de projet de savoir qu'une mise à jour est prête à être intégrée. La pull request sert également de fil de discussion, ce qui s'avère pratique en cas de problème avec le code contribué. Voici un exemple étape par étape de ce workflow.

 

  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 master locale, puis pushe la branche master 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.

Duplication (fork) et clonage

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. 

Création de branche dans le workflow de duplication

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.

Forker un dépôt

Worklow de duplication (fork) Git – Forker un dépôt

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.

Cloner votre fork

À présent, chaque développeur doit dupliquer son propre dépôt forké public. Pour ce faire, les développeurs peuvent utiliser la commande bien connue git clone.

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 :

git clone https://user@bitbucket.org/user/repo.git

Ajout d'un remote

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.

git remote add upstream https://bitbucket.org/maintainer/repo

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 :

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

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.

Travail dans une branche : apporter des changements et les pusher

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 :

git checkout -b some-feature
# Vous éditez le code
git commit -a -m "J'ai ajouté la première ébauche d'une fonctionnalité donnée"

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 :

git pull upstream master

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.

Faire une pull request

Workflows de duplication (fork) Git – Faire une pull request

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 :

git push origin feature-branch

À 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 faire un merge de leurs fonctionnalités dans la base de code officielle, ils doivent en informer le mainteneur de projet. Sur 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 master du dépôt distant en amont.

Summary

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.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant