dev Forking vs. Branching dans GitHub




github workflow (4)

J'aimerais en savoir plus sur les avantages et les inconvénients de forger un projet github par opposition à la création d'une branche d'un projet github.

Forking rend ma version du projet plus isolée de l'original car je n'ai pas besoin d'être sur la liste des collaborateurs du projet original. Puisque nous développons un projet à l'interne, il n'y a aucun problème à ajouter des personnes en tant que collaborateurs. Mais, nous aimerions comprendre si le fait de forger un projet rendrait plus difficile la fusion des modifications vers le projet principal. C'est-à-dire que je me demande si l'embranchement rend plus facile la synchronisation des deux projets. En d'autres termes, est-il plus facile de fusionner et de pousser les changements entre ma version du projet principal et le projet principal lorsque je branche?


Forking crée un référentiel entièrement nouveau à partir du référentiel existant (en faisant simplement git clone sur gitHub / bitbucket)

Les fourchettes sont les mieux utilisées: lorsque l'objectif de la «scission» est de créer un projet logiquement indépendant, qui ne pourra jamais être réuni avec son parent.

La stratégie de branche crée une nouvelle branche sur le référentiel existant / actif

Les branches sont mieux utilisées: lorsqu'elles sont créées en tant que lieux temporaires pour travailler à travers une entité, avec l'intention de fusionner la branche avec l'origine.

Plus spécifique: - Dans les projets open source, c'est le propriétaire du référentiel qui décide qui peut pousser vers le référentiel. Cependant, l'idée de l'open source est que tout le monde peut contribuer au projet.

Ce problème est résolu par les fourches: chaque fois qu'un développeur souhaite modifier quelque chose dans un projet open source, il ne clone pas le référentiel officiel directement. Au lieu de cela, ils le fourchent pour créer une copie. Lorsque le travail est terminé, ils effectuent une requête de traction afin que le propriétaire du référentiel puisse examiner les modifications et décider s'il doit les fusionner avec son projet.

À la base, le forking est similaire au branchement d'entités, mais au lieu de créer des branches, une fourchette du référentiel est créée, et au lieu de faire une demande de fusion, vous créez une requête pull.

Les liens ci-dessous fournissent la différence d'une manière bien expliquée:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html


Vous ne pouvez pas toujours créer une branche ou tirer une branche existante et y repasser, car vous n'êtes pas enregistré en tant que collaborateur pour ce projet spécifique.

Forking n'est rien d'autre qu'un clone du côté du serveur GitHub :

  • sans possibilité de repousser directement
  • avec fonctionnalité de file d' attente de fourche ajoutée pour gérer la demande de fusion

Vous maintenez une fourche synchronisée avec le projet d'origine en:

  • ajouter le projet d'origine en tant que télécommande
  • aller chercher régulièrement de ce projet original
  • Rebase votre développement actuel au-dessus de la branche d'intérêt que vous avez mise à jour à partir de cette récupération.

La rebase vous permet de vous assurer que vos modifications sont simples (aucun conflit de fusion à gérer), ce qui rend votre requête d'extraction plus facile lorsque vous souhaitez que le responsable du projet d'origine inclue vos correctifs dans son projet.

L'objectif est vraiment de permettre la collaboration même si la participation directe n'est pas toujours possible.

Le fait que vous clonez sur le côté GitHub signifie que vous avez maintenant deux référentiels «centraux» («central» comme «visibles de plusieurs collaborateurs).
Si vous pouvez les ajouter directement en tant que collaborateur pour un projet, vous n'avez pas besoin d'en gérer un autre avec une fourchette.

L'expérience de fusion serait à peu près la même, mais avec un niveau supplémentaire d'indirection (pousser d'abord sur la fourche, puis demander une traction, avec le risque d'évolutions sur le repo original rendant vos fusions rapides plus rapides) .
Cela signifie que le flux de travail correct est de git pull --rebase upstream (rebaser votre travail en amont des nouvelles git pull --rebase upstream amont), puis git push --force origin , afin de réécrire l'historique de manière à ce que vos propres commits soient toujours au-dessus des commits du repo original (en amont).

Voir également:

  • Git fork est git clone?
  • Tirez les nouvelles mises à jour du référentiel Github original vers le référentiel Github forké

Cela a à voir avec le flux de travail général de Git. Vous avez peu de chances de pouvoir accéder directement au référentiel du projet principal. Je ne suis pas sûr que le référentiel du projet GitHub prenne en charge le contrôle d'accès basé sur une branche, car vous ne voudriez accorder à personne l'autorisation de pousser vers la branche maître par exemple.

Le modèle général est le suivant:

  • Fourchez le référentiel du projet d'origine pour avoir votre propre copie de GitHub, à laquelle vous serez ensuite autorisé à pousser les modifications.
  • Clonez votre référentiel GitHub sur votre machine locale
  • Facultativement, ajoutez le référentiel d'origine en tant que référentiel distant supplémentaire sur votre référentiel local. Vous serez alors en mesure d'extraire les modifications publiées dans ce référentiel directement.
  • Faites vos modifications et vos propres commits localement.
  • Poussez vos modifications dans votre dépôt GitHub (car vous n'aurez généralement pas les permissions d'écriture sur le dépôt du projet directement).
  • Contactez les responsables du projet et demandez-leur d'aller chercher vos modifications et de les réviser / fusionner, et de les laisser revenir au référentiel du projet (si vous et eux le souhaitez).

Sans cela, il est assez rare que des projets publics permettent à quiconque de pousser directement ses propres commits.


Voici les différences de haut niveau:

Forking

Avantages

  • Maintient les branches séparées par l'utilisateur
  • Réduit l'encombrement dans le référentiel principal
  • Votre processus d'équipe reflète le processus de contributeur externe

Les inconvénients

  • Il est plus difficile de voir toutes les succursales qui sont actives (ou inactives, d'ailleurs)
  • Collaborer sur une branche est plus délicat (le propriétaire de la fourchette doit ajouter la personne en tant que collaborateur)
  • Vous devez comprendre le concept des télécommandes multiples dans Git
    • Nécessite une comptabilité mentale supplémentaire
    • Cela rendra le flux de travail plus difficile pour les personnes qui ne sont pas très à l'aise avec Git

Branchement

Avantages

  • Maintient tout le travail effectué autour d'un projet en un seul endroit
  • Tous les collaborateurs peuvent pousser à la même branche pour y collaborer
  • Il n'y a qu'une seule télécommande Git à gérer

Les inconvénients

  • Les branches abandonnées peuvent s'accumuler plus facilement
  • Le processus de contribution de votre équipe ne correspond pas au processus de contribution externe
  • Vous devez ajouter des membres de l'équipe en tant que contributeurs avant de pouvoir créer une branche




github