Les fourches Git sont-elles réellement des clones Git?

817

Je n'arrête pas d'entendre des gens dire qu'ils bifurquent du code dans Git. Git "fork" ressemble étrangement à Git "clone" plus une certaine volonté psychologique (sans signification) de renoncer aux futures fusions. Il n'y a pas de commande fork dans Git, non?

GitHub rend les fourches un peu plus réelles en y agrafant de la correspondance. Autrement dit, vous appuyez sur le bouton de fourche et plus tard, lorsque vous appuyez sur le bouton de demande de traction, le système est suffisamment intelligent pour envoyer un e-mail au propriétaire. Par conséquent, c'est un peu une danse autour de la propriété et des autorisations du référentiel.

Oui Non? Une angoisse sur GitHub étendant Git dans cette direction? Ou des rumeurs selon lesquelles Git absorbe la fonctionnalité?

— Brian
source

10

Oui, c'est juste un type de clone qui est suivi par la base de données github.

— Paŭlo Ebermann

15

GitHub ne fait-il pas quelque chose de spécial pour éviter de doubler les exigences de stockage (sur les propres serveurs de GitHub)?

— Keith Thompson

18

Pas encore mentionné: la suppression d'un référentiel privé supprime toutes ses fourches. La suppression d'un référentiel public conserve les fourches mais promeut qu'un fork est le nouveau référentiel parent. Si votre patron rend votre référentiel public privé, il casse toutes les fourches existantes et vous ne pourrez pas en faire de demande au référentiel privé. help.github.com/articles/…

— Platon

Je crois (sans preuve puisque GitHub ne nous le montre pas) que le véritable mécanisme ici est les "suppléants" de Git. En d'autres termes, la fourche est un clone miroir --referenceutilisé. La façon exacte dont les dépôts et suppressions publics sont traités n'est pas du tout claire (déplacer les remplaçants vers un référentiel promu choisi au hasard? Pointer toutes les fourchettes vers un remplaçant commun qui ne fait pas partie de la fourche d'origine?), Mais l'utilisation d'alternatives explique divers comportements observables.

— torek

925

Fork , dans le contexte GitHub, n'étend pas Git.
Il autorise uniquement le clonage côté serveur.

Lorsque vous clonez un référentiel GitHub sur votre poste de travail local, vous ne pouvez pas contribuer à nouveau au référentiel en amont, sauf si vous êtes explicitement déclaré comme "contributeur". C'est parce que votre clone est une instance distincte de ce projet. Si vous souhaitez contribuer au projet, vous pouvez utiliser forking pour le faire, de la manière suivante:

cloner ce référentiel GitHub sur votre compte GitHub (c'est-à-dire la partie "fork" , un clone côté serveur)
contribue à ce dépôt GitHub (il se trouve dans votre propre compte GitHub, vous avez donc le droit d'y accéder)
signaler toute contribution intéressante au référentiel GitHub d'origine (c'est-à-dire la partie "pull request" au moyen des modifications que vous avez apportées à votre propre référentiel GitHub)

Vérifiez également " Workflow collaboratif GitHub ".

Si vous souhaitez conserver un lien avec le référentiel d'origine (également appelé en amont), vous devez ajouter une télécommande référençant ce référentiel d'origine.
Voir " Quelle est la différence entre l'origine et l'amont sur GitHub? "

fourche et en amont

Et avec Git 2.20 (Q4 2018) et plus, la récupération depuis la fourche est plus efficace, avec les îles delta .

— VonC
source

6

"Lorsque vous clonez un référentiel GitHub sur votre poste de travail local, vous ne pouvez pas contribuer à nouveau au référentiel en amont, sauf si vous êtes explicitement déclaré comme" contributeur "." --- N'est-ce pas vrai avec "forking"? S'il vous plaît, expliquez.

— chharvey

61

@ TestSubject528491 non, avec un fork, cela signifie que vous clonez le référentiel en amont en tant que votre propre référentiel côté serveur GitHub. Ensuite, vous pouvez cloner localement ce nouveau dépôt "fork" sur votre ordinateur et le repousser librement, car vous êtes le créateur et le propriétaire de ce fork.

— VonC du

9

Pour moi, le point clé est que vous ne pouvez pas soumettre de RP à partir de votre copie locale à moins d'être déclaré contributeur . Je suis tellement habitué à soumettre des RP de mon référentiel local, mais c'est parce que je suis toujours marqué comme contributeur. Si vous y pensez, pour soumettre un PR, vous devez pousser une branche vers le référentiel distant, puis créer le PR. Je suppose que cela a du sens si vous ne voulez pas que des personnes aléatoires créent des branches sur votre repo. Et que vous préférez qu'ils le fourchent et soumettent des RP de cette façon à la place.

— Adam Zerner

J'ai vu la deuxième approche à distance "en amont" ailleurs, mais n'est-il pas plus simple de passer directement de "GitHub - Original" à "GitHub - Fork"? La deuxième approche à distance ne semblait pas fonctionner dans ma configuration Eclipse et eGit, ne parvenant pas à pousser vers mon dépôt "GitHub - Fork" (rien à pousser).

— William T. Mallard

Peu importe, le lien info ici m'a donné un aperçu. En tant que contributeur, il est logique de passer de "GitHub - Original" à "GitHub - Fork", puis de "- Fork" à la machine locale, mais si vous êtes le propriétaire, vous voudrez probablement tirer directement de mon "- Fork" examiner, exécuter des tests, etc. avant de passer à "- Original".

— William T. Mallard

135

Je n'arrête pas d'entendre les gens dire qu'ils forks du code dans git. Git "fork" ressemble étrangement à git "clone" plus une certaine volonté psychologique (dénuée de sens) de renoncer à de futures fusions. Il n'y a pas de commande fork dans git, non?

"Forking" est un concept, pas une commande spécifiquement prise en charge par un système de contrôle de version.

Le type de fourche le plus simple est synonyme de ramification. Chaque fois que vous créez une branche, quel que soit votre VCS, vous avez "fourchu". Ces fourches sont généralement assez faciles à fusionner.

Le type de fourchette dont vous parlez, où une partie distincte prend une copie complète du code et s'en va, se produit nécessairement en dehors du VCS dans un système centralisé comme Subversion. Un VCS distribué comme Git a un bien meilleur support pour bifurquer la base de code entière et démarrer efficacement un nouveau projet.

Git (et non GitHub) prend en charge nativement le "forking" d'un dépôt entier (c'est-à-dire le clonage) de deux manières:

lorsque vous clonez, une télécommande appelée originest créée pour vous
par défaut, toutes les branches du clone suivront leurs originéquivalents
la récupération et la fusion des modifications à partir du projet d'origine à partir duquel vous avez effectué une fourche est très simple

Git rend les modifications apportées à la source du fork aussi simples que de demander à quelqu'un du projet d'origine de vous retirer ou de demander un accès en écriture pour repousser les modifications vous-même. C'est la partie que GitHub facilite et standardise.

Y a-t-il de l'angoisse à propos de Github étendant git dans cette direction? Ou des rumeurs de git absorbant la fonctionnalité?

Il n'y a pas d'angoisse parce que votre hypothèse est fausse. GitHub « étend » la fonctionnalité de fork Git avec une interface graphique agréable et d' une manière standardisée d'émettre des demandes de tirage, mais il n'a pas ajouter la fonctionnalité à Git. Le concept de repo-forking complet est directement intégré au contrôle de version distribué à un niveau fondamental. Vous pouvez abandonner GitHub à tout moment et continuer à pousser / tirer des projets que vous avez "bifurqués".

— meagar
source

6

Merci pour votre excellente réponse. Je veux juste clarifier, cela signifie, en dehors du contexte de github, je pourrais en cloner quelques-uns X projectsur ma machine. Si j'apporte des modifications dans mon local et que je n'ai pas accès en écriture à l'origine, j'enverrai un e-mail à l'auteur du projet pour demander un pull. Il fera une télécommande appelée gideon qui sera une URL pour mon clone local, et il peut tirer, non?

— gideon

1

Si vous souhaitez apporter vos modifications à un projet, vous pouvez soit les enregistrer dans des fichiers, par exemple en utilisant git format-patch et les joindre à un e-mail à quelqu'un qui a cet accès en écriture, ou vous pouvez obtenir votre propre hébergement, pousser votre travail vers celui-ci et envoyer l'URL dans un e-mail, par exemple en utilisant la commande git request-pull. Les dépôts sur les postes de travail ne sont généralement pas directement accessibles en ligne.

— bdsl

Mais oui, si votre poste de travail est accessible sur Internet à l'auteur du projet, vous pouvez simplement leur envoyer l'URL et ils peuvent l'ajouter en tant que télécommande et en tirer.

— bdsl

1

Re: angst, le seul pour moi est qu'il n'y a pas de lien ou de bouton sur lequel cliquer pour créer un bouton en perspective tirée de mon référentiel où GitHub vous indique que vous avez 50 commits derrière. Pas de problème maintenant que je sais qu'ils utilisent le terme "Pull Request" pour inclure également les demandes de tirage de l'amont vers votre fork GitHub. Git est dur.

— William T. Mallard

80

Oui, fork est un clone. Il est apparu parce que vous ne pouvez pas pousser les copies des autres sans leur permission . Ils en font une copie pour vous ( fork ), où vous aurez également la permission d'écrire.

À l'avenir, si le propriétaire réel ou d'autres utilisateurs avec un fork aiment vos modifications, ils peuvent le récupérer dans leur propre référentiel. Vous pouvez également leur envoyer une "pull-request".

— ssapkota
source

Puis-je simplement cloner le référentiel sur ma machine locale, créer une branche, puis soumettre une demande d'extraction au propriétaire d'origine? Il semble redondant d'avoir plusieurs copies de dépôts hébergées partout dans GitHub, juste pour faciliter les mises à jour du code.

— Casey

4

@Casey Vous ne pouvez envoyer une demande d'extraction via GitHub que depuis GitHub lui-même et vous ne pouvez envoyer une demande d'extraction GitHub qu'à partir d'une branche qui existe sur GitHub. Si vous n'êtes pas un collaborateur sur le référentiel en question, il n'y a aucun moyen pour vous de créer une branche à partir de laquelle vous pouvez lancer une demande d'extraction GitHub. Rien ne vous empêche de le faire par e-mail à l'ancienne, mais GitHub n'y joue aucun rôle.

— Beau Simensen

2

@Casey, une raison est que normalement, les autres n'ont pas accès URL à votre poste de travail. Le GitHub forksignifie qu'il existe une copie de votre travail sur le serveur GitHub, que vous pouvez pushconsulter et à laquelle d'autres ont accès par URL pour qu'ils puissent pull. Le pull requestest juste un moyen standard de leur envoyer l'URL de votre copie (sur GitHub) afin qu'ils puissent facilement la glisser dans leur référentiel.

— Jesse Chisholm

Cela devrait être la réponse correcte / acceptée, je crois. Imaginez un gâchis dans une scène où une équipe de 15-20 développeurs créant des branches et poussant vers l'origine contre 15-20 développeurs ayant leur propre copie du même référentiel et faisant autant de branches et faisant des changements et les repoussant. Ensuite, l'auteur du référentiel d'origine ne peut extraire que les modifications qu'il souhaite.

— Kishor Pawar

37

"Fork" dans ce contexte signifie "Faire une copie de leur code afin que je puisse ajouter mes propres modifications". Il n'y a pas grand chose d'autre à dire. Chaque clone est essentiellement une fourchette, et c'est à l'original de décider de retirer ou non les modifications de la fourchette.

— Daenyth
source

2

En particulier: "Faites une copie de leur code on the GitHub serverafin que je puisse ajouter mes propres modifications and others can have URL access to my version". La plupart des postes de travail locaux n'offrent pas d'accès URL pour que quiconque puisse tirer. Mais si vous poussez vers votre fork sur le serveur, ils peuvent avoir l'URL pour le pull.

— Jesse Chisholm

La question ne concerne pas le forking en général, mais le GitHub en particulier.

— reinierpost

26

Le clonage implique de faire une copie du référentiel git sur une machine locale, tandis que forking clone le référentiel dans un autre référentiel. Le clonage est réservé à un usage personnel (bien que de futures fusions puissent se produire), mais avec la fourche, vous copiez et ouvrez un nouveau chemin de projet possible

— Sam Johnson
source

11

Le fork est fait lorsque vous décidez de contribuer à un projet. Vous feriez une copie de l'ensemble du projet avec ses journaux d'historique. Cette copie est entièrement effectuée dans votre référentiel et une fois que vous avez effectué ces modifications, vous émettez une demande de tirage. Il appartient maintenant au propriétaire de la source d'accepter votre demande d'extraction et d'incorporer les modifications dans le code d'origine.

Git clone est une commande réelle qui permet aux utilisateurs d'obtenir une copie de la source. git clone [URL] Cela devrait créer une copie de [URL] dans votre propre référentiel local.

— aliasav
source

10

Je pense que fork est une copie d'un autre référentiel mais avec la modification de votre compte. par exemple, si vous clonez directement un autre référentiel localement, l'origine de l'objet distant utilise toujours le compte à partir duquel vous clonez. Vous ne pouvez pas valider et contribuer votre code. Ce n'est qu'une pure copie de codes. Sinon, si vous créez un référentiel, il clonera le dépôt avec la mise à jour des paramètres de votre compte dans votre compte github. Et puis en clonant le dépôt dans le contexte de votre compte, vous pouvez valider vos codes.

— Daniel Shen
source

10

Il y a un malentendu ici en ce qui concerne ce qu'est une «fourchette». Un fork n'est en fait rien de plus qu'un ensemble de branches par utilisateur. Lorsque vous poussez vers un fork, vous poussez réellement vers le référentiel d'origine, car il s'agit du SEUL référentiel.

Vous pouvez essayer cela en poussant vers une fourchette, en notant la validation, puis en vous rendant dans le référentiel d'origine et en utilisant l'ID de validation, vous verrez que la validation est "dans" le référentiel d'origine.

Cela a beaucoup de sens, mais c'est loin d'être évident (je ne l'ai découvert que accidentellement récemment).

Lorsque John forks repository SuperProject, ce qui semble réellement se produire, c'est que toutes les branches du référentiel source sont répliquées avec un nom comme "John.master", "John.new_gui_project", etc.

GitHub "cache" le "John". de nous et nous donne l'illusion que nous avons notre propre "copie" du référentiel sur GitHub, mais nous n'en avons pas et nous n'en avons même pas besoin.

Ainsi, la branche de ma fourchette "master" est en fait nommée "Korporal.master", mais l'interface utilisateur de GitHub ne le révèle jamais, ne me montrant que "master".

C'est à peu près ce que je pense de toute façon sous le capot, basé sur des choses que j'ai faites récemment et quand vous y réfléchissez, c'est un très bon design.

Pour cette raison, je pense qu'il serait très facile pour Microsoft d'implémenter les fourches Git dans leur offre Visual Studio Team Services.

— Hugh
source

Cher Hugh, la moitié de votre réponse est en fait incorrecte - une fourchette est un clone d'un référentiel entier d'un compte d'utilisateur à un autre compte d'utilisateur, avec toutes les branches et l'historique. Lorsque vous vous engagez sur le fork, rien ne change dans le référentiel d'origine à partir duquel vous avez forké. Mais à part ces quelques malentendus de votre part concernant ce qu'est un «fork», il y a maintenant de bonnes nouvelles: les services Visual Studio Team incluent désormais une fonctionnalité «Fork». ;)

— Sorin Postelnicu

1

@SorinPostelnicu source? Je suis enclin à croire Hugh ici en raison de l'expérience personnelle des fourches qui se comportent de manière inconstante, car elles sont un simple clone du référentiel. Par exemple, lorsque l'amont est supprimé, les fourches sont supprimées (comme cela a été mentionné dans un commentaire sur la question de OP) et parfois l'amont a fini par fusionner des choses dans les branches de mes fourches lors de l'acceptation d'une demande de tirage, sans que je fasse quoi que ce soit.

— pomme de terre

En effet, cela semble être le cas. Après tout, il serait incroyablement stupide pour GitHub de littéralement git cloneun tout nouveau référentiel (même un "nu") chaque fois que quelqu'un appuie sur le bouton "fork" - ce serait un gaspillage de stockage incroyable, et probablement un vecteur d'attaque également .

— Greg A. Woods

7

Mis à part le fait que le clonage s'effectue du serveur vers votre machine et que forking effectue une copie sur le serveur lui-même, une différence importante est que lorsque nous clonons, nous obtenons en fait toutes les branches, étiquettes, etc.

Mais lorsque nous bifurquons, nous n'obtenons en fait que les fichiers actuels dans la branche master, rien d'autre. Cela signifie que nous n'obtenons pas les autres succursales, etc.

Par conséquent, si vous devez fusionner quelque chose dans le référentiel d'origine, il s'agit d'une fusion inter-référentiel et nécessitera certainement des privilèges plus élevés.

Fork n'est pas une commande dans Git; c'est juste un concept que GitHub implémente. N'oubliez pas que Git a été conçu pour fonctionner dans un environnement peer-to-peer sans avoir besoin de synchroniser des éléments avec une copie principale. Le serveur n'est qu'un autre pair, mais nous le considérons comme une copie principale.

— Deepak GM
source

7

Hein? Une fourche récupère toutes les branches, mais vous devez savoir où chercher (indice:) git branch -a.

— tripleee

3

En termes plus simples,

Quand tu dis que tu bifurques un référentiel, vous créez essentiellement une copie du référentiel d'origine sous votre ID GitHub dans votre compte GitHub.

et

Lorsque vous dites que vous clonez un référentiel, vous créez une copie locale du référentiel d'origine dans votre système (PC / ordinateur portable) directement sans avoir de copie dans votre compte GitHub.

— anoNewb
source