Forking vs Branching dans GitHub

278

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

Forking rend ma version du projet plus isolée de celle d'origine car je n'ai pas besoin d'être sur la liste des collaborateurs du projet original. Puisque nous développons un projet en interne, il n'y a aucun problème à ajouter des personnes en tant que collaborateurs. Mais, nous aimerions comprendre si le fait de bifurquer un projet rendrait les modifications de fusion au projet principal plus difficiles. Autrement dit, je me demande si la ramification facilite 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?

git branch github

— reprogrammeur
source

280

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

Forking n'est rien de plus qu'un clone côté serveur GitHub :

sans possibilité de repousser directement
avec la fonction de file d' attente fork ajoutée pour gérer la demande de fusion

Vous gardez un fork synchronisé avec le projet d'origine en:

ajout du projet d'origine en tant que télécommande
aller chercher régulièrement à partir de ce projet original
rebaser votre développement actuel au-dessus de la branche d'intérêt que vous avez mise à jour à partir de cette extraction.

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

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

Le fait que vous cloniez du côté de GitHub signifie que vous avez maintenant deux référentiels "centraux" ("centraux" comme "visibles par 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 une avec une fourchette.

fourche sur GitHub

L'expérience de fusion serait à peu près la même, mais avec un niveau d'indirection supplémentaire (poussez d'abord sur la fourche, puis demandez une traction, avec le risque d'évolutions sur le référentiel d'origine, ce qui rend vos fusions rapides plus rapides) .
Cela signifie que le flux de travail correct consiste à git pull --rebase upstream(rebaser votre travail au-dessus des nouvelles validations à partir de l'amont), puis git push --force origin, afin de réécrire l'historique de telle manière que vos propres validations sont toujours au-dessus des validations du référentiel d' origine (en amont) .

Voir également:

— VonC
source

3

Nous développons un projet en interne et il n'y a aucun problème à ajouter des personnes en tant que collaborateurs. Mais, nous aimerions comprendre si le fait de bifurquer un projet rendrait plus difficile la fusion des modifications au projet principal.

— reprogrammeur

7

@reprogrammer: si vous pouvez ajouter des collaborateurs, alors la fourche n'est pas nécessaire. ils peuvent rebaser localement puis fusionner sur la branche cible, puis pousser directement vers un seul référentiel central, au lieu d'avoir à gérer deux référentiels centraux (l'original et le fork). Le rebase serait à peu près le même, mais avec une indirection supplémentaire quand un fork est impliqué. Encore une fois: pas nécessaire ici. J'ai mis à jour ma réponse.

— VonC

14

Honnêtement, même si vous n'êtes pas obligé, c'est toujours une bonne idée d' avoir un dépôt sacré qui n'est accessible qu'en écriture pour les développeurs seniors, les chefs d'équipe ou d'autres personnes "de confiance" . Tous les autres membres de l'équipe doivent travailler dans leurs fourches (~ bacs à sable) et apporter leurs modifications sous la forme d'une demande d'extraction. Comme DVCS le permet, nous l'avons adapté en tant que "meilleure pratique" et nous l'utilisons avec succès même dans les plus petits projets ...

— intland

1

@intland vous êtes donc plutôt en faveur d'un "workflow de gestionnaire d'intégration" comme décrit dans stackoverflow.com/users/6309/vonc?tab=responses alors? Pour avoir introduit Git dans un grand corp, j'ai tendance à adopter d'abord un workflow centralisé (plus familier à tout le monde), avant de passer à un «gestionnaire d'intégration».

— VonC

15

Nous devrions appeler les fourches "brindilles" car elles sont coupées d'une branche et sont utilisées pour démarrer un tout nouvel arbre. Juste mes deux cents - j'aime l'idiome arboricole.

— Eric

67

Voici les différences de haut niveau:

Forking

Avantages

Garde 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 contribution externe

Les inconvénients

Rend plus difficile de voir toutes les branches actives (ou inactives d'ailleurs)
Collaborer sur une branche est plus délicat (le propriétaire de fork doit ajouter la personne en tant que collaborateur)
Vous devez comprendre le concept de plusieurs télécommandes 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

Ramification

Avantages

Conserve tout le travail effectué autour d'un projet en un seul endroit
Tous les collaborateurs peuvent pousser vers 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'empiler 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

— Aidan Feldman
source

Qu'entend-on par «le processus de contribution externe»?

— Kars Barendrecht

1

@KarsBarendrecht Mise à jour pour utiliser le terme "contributeur externe". Quelqu'un qui n'a pas d' writeautorisations sur le référentiel.

— Aidan Feldman

45

Cela a à voir avec le flux de travail général de Git. Il est peu probable que vous puissiez accéder directement au référentiel du projet principal. Je ne sais pas si le référentiel du projet GitHub prend en charge le contrôle d'accès basé sur une branche, car vous ne voudriez pas accorder à quiconque la permission de pousser vers la branche principale par exemple.

Le schéma général est le suivant:

Forkez le référentiel du projet d'origine pour avoir votre propre copie GitHub, vers laquelle vous serez ensuite autorisé à pousser les modifications.
Clonez votre référentiel GitHub sur votre machine locale
Vous pouvez éventuellement ajouter le référentiel d'origine en tant que référentiel distant supplémentaire sur votre référentiel local. Vous pourrez ensuite récupérer directement les modifications publiées dans ce référentiel.
Faites vos modifications et vos propres commits localement.
Poussez vos modifications dans votre référentiel GitHub (car vous n'aurez généralement pas les autorisations d'écriture directement sur le référentiel du projet).
Contactez les responsables du projet et demandez-leur de récupérer vos modifications et de les réviser / fusionner, et laissez-les repousser vers le référentiel du projet (si vous et eux le souhaitez).

Sans cela, il est assez inhabituel pour des projets publics de laisser quiconque pousser ses propres engagements directement.

— Bruno
source

@RecoJohnson, eh bien ... Je n'ai pas utilisé le mot "pull" dans ma réponse (mais "pull" est effectivement "fetch" + "merge" en termes Git). Selon vous, quel usage de «push» est mauvais?

— Bruno

2

@RecoJohnson Vous en tant que contributeur push à votre fork GitHub; les responsables du projet tirent votre contribution de votre fourchette.

— mljrg

1

Je pense que l'hypothèse selon laquelle il est peu probable que l'on vous attribue un collaborateur est plus vraie dans le monde open source que dans de nombreuses organisations avec des équipes de développement utilisant maintenant git où l'équipe de développement est bien définie. Je pense que c'est une distinction importante à faire et qui n'est pas assez faite, probablement pourquoi des entreprises comme gitlab prospèrent parce qu'elles comprennent les besoins de l'entreprise et le besoin de contrôles.

— code4cause

9

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

Les fourches sont mieux utilisées: lorsque l'intention de la `` scission '' est de créer un projet logiquement indépendant, qui peut ne jamais se réunir avec son parent.

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

Les branches sont mieux utilisées: lorsqu'elles sont créées en tant qu'espaces temporaires pour travailler sur une fonction, 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 veut changer quelque chose dans un projet open source, il ne clone pas directement le référentiel officiel. Au lieu de cela, ils le fourchent pour créer une copie. Une fois le travail terminé, ils font une demande d'extraction afin que le propriétaire du référentiel puisse examiner les modifications et décider de les fusionner avec son projet.

À la base, la fourche est similaire à la fonction de branchement, 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 demande d'extraction.

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

— qui suis je
source

Les déclarations «les mieux utilisées» dans cette réponse semblent ignorer bon nombre des problèmes qui empêchent la branche de fonctionner pour des choses comme les projets open-source, ainsi que la réalité de l'utilisation des fourches dans le monde réel. Il est extrêmement courant de voir des fourches utilisées conjointement avec des demandes d'extraction pour permettre aux personnes de collaborer sur un projet qui n'ont pas toutes les autorisations pour modifier directement un référentiel donné.

— StriplingWarrior