Pour les personnes qui atterrissent ici à la recherche d'une explication de "fork" avec Git (pas GitHub). Il n'y a pas de commande "fork" sur Git. C'est plus un concept GitHub (pas Git). Une distinction facilement oubliée.
ambassallo
Réponses:
113
En gros, oui. A forkest juste une demande à GitHub de cloner le projet et de l'enregistrer sous votre nom d'utilisateur ; GitHub garde également une trace de la relation entre les deux référentiels, afin que vous puissiez visualiser les commits et les pulls entre les deux projets (et d'autres forks).
Vous pouvez toujours demander que les gens tirent de votre référentiel cloné, même si vous ne l'utilisez pas fork, mais vous devrez vous occuper de le rendre public vous-même. Ou envoyez aux développeurs des correctifs (voir git format-patch) qu'ils peuvent appliquer à leurs arbres.
La mise à jour des fourches demande beaucoup plus de travail que des clones. Un clone peut être mis à jour avec un simple git pull. Un fork prend plusieurs commandes. Et ce n'est pas surprenant, presque toutes les fourches que je regarde sont obsolètes. Les fourches sont comme le problème du référentiel Maven sur les stéroïdes. Au lieu d'un dépôt obsolète (Maven), il y en a des milliers (Git).
jww
@jww sonne comme il est préférable de s'en tenir au clone - pourquoi utiliser fork alors?
serup du
@serup - la raison en est que la copie fourchue peut être modifiée git pullafin qu'il y ait encore une sorte de relation qui existe. Si vous avez cloné l'intégralité de la copie, elle repose sur votre propre machine locale et est déconnectée du dépôt d'origine.
JonH
134
Lorsque vous dites que vous forkez un référentiel, vous créez essentiellement une copie du référentiel sous votre ID GitHub. Le point principal à noter ici est que toutes les modifications apportées au référentiel d'origine seront reflétées dans vos référentiels fourchus (vous devez récupérer et rebaser). Cependant, si vous apportez des modifications à votre référentiel forké , vous devrez créer explicitement une pull request vers le référentiel d' origine . Si votre demande d'extraction est approuvée par l'administrateur du référentiel d'origine , vos modifications seront validées / fusionnées avec la base de code d' origine existante . Jusque-là, vos modifications ne seront reflétées que dans la copie que vous avez fourchée .
En bref:
Le modèle Fork & Pull permet à quiconque de fork un référentiel existant et de pousser les modifications vers son fork personnel sans avoir besoin d'un accès au référentiel source. Les modifications doivent ensuite être extraites dans le référentiel source par le responsable du projet.
Notez qu'après avoir forgé, vous pouvez cloner votre référentiel (celui sous votre nom) localement sur votre machine. Apportez-y des modifications et transférez-le dans votre référentiel forké. Cependant, pour refléter vos modifications dans le référentiel d'origine, votre demande d'extraction doit être approuvée.
"Le point principal à noter ici est que toutes les modifications apportées au référentiel d'origine seront reflétées dans vos référentiels fourchus." C'est un peu trompeur, je pense. AFAIK, les modifications apportées au référentiel d'origine après le fork ne sont pas automatiquement reflétées dans le fork; vous devez déplacer ces modifications manuellement. Les changements survenus avant le fork sont cependant copiés dans le nouveau fork lorsque vous cliquez sur le bouton fork.
Ajedi32 du
"toute modification apportée au référentiel d'origine sera reflétée dans vos référentiels fourchus" .. vraiment ?? Pas automatiquement j'espère
KansaiRobot
Je travaillais pour le projet d'un client et j'utilisais le clonage et le modèle push pour mon travail. Un jour, je l'ai fourché et j'ai immédiatement reçu un message indiquant la nécessité de fourcher le repo complet. Je ne comprends vraiment pas comment cela est considéré comme faux?
user3075740
les modifications apportées au référentiel d'origine après le fork ne sont pas automatiquement reflétées dans le fork, mais pour ce faire, consultez l'étape 3 de ce blog: - help.github.com/articles/fork-a-repo
Suhas Chikkanna
"toute modification apportée au référentiel d'origine sera reflétée dans vos référentiels fourchus" - voulez-vous dire que ce n'est pas possible après le clonage?
variable le
26
Le projet forké se trouve sur votre référentiel en ligne (repo).
Le projet cloné est sur votre machine locale (je clone généralement après avoir forking le dépôt).
Vous pouvez vous engager sur votre repo en ligne (ou vous engager sur votre repo local, puis pousser vers votre repo en ligne), puis envoyer une pull request.
Le chef de projet peut l'accepter pour obtenir vos modifications dans sa version principale en ligne.
Un clone est l'endroit où vous avez une duplication et une séparation appropriées entre deux versions (éventuellement différentes) d'un référentiel. Lorsqu'un dépôt est modifié, le nouveau contenu doit être copié activement dans l'autre dépôt à l'aide d'une commande push. Et les modifications de l'autre repo récupérées.
Lorsque vous forkez un dépôt, sur un serveur, il n'est pas nécessaire de dupliquer le contenu car les deux dépôts utiliseront le même contenu [objet fixe] de ce même serveur. L'astuce consiste à gérer les différents points de vue des utilisateurs afin que chaque utilisateur pense avoir une copie personnelle complète du dépôt. Les poussées et les récupérations entre les fourches mettent simplement à jour les pointeurs de l'utilisateur.
À un niveau inférieur, git fait la même chose en interne. Si vous avez trois fichiers différents, chacun contenant Hello World, alors git `` fourche '' simplement sa copie unique de l'objet blob Hello World et l'offre à chacun des trois endroits selon les besoins.
La possibilité de fork sur le serveur signifie que la grande allocation de stockage de Github n'est pas si grande en moyenne, car tout le monde partage le seul repo sous-jacent.
En un mot, Forking est peut-être la même chose que "cloner sous votre ID / profil GitHub". Un fork est à tout moment meilleur qu'un clone, à quelques exceptions près, évidemment. Le référentiel forké est toujours surveillé / comparé au référentiel d'origine contrairement à un référentiel cloné. Cela vous permet de suivre les modifications, de lancer des demandes d'extraction et de synchroniser manuellement les modifications apportées dans le référentiel d'origine avec votre référentiel forké.
Alors que la réponse de @ AniketThakur est très bonne. Personne n'a encore répondu à la question suivante.
Puis-je envoyer des pull requests via GitHub uniquement si j'ai forké un projet?
Non. Si vous contribuez à un référentiel, vous pouvez: Créer un clone local. Créez une succursale locale. Ajoutez des commits à cette branche. Poussez la branche locale vers github (création d'une branche distante dans le processus). Faites une pull request demandant que cette branche soit fusionnée dans la branche principale (ou la branche de votre choix).
Dans le cas où vous avez fait ce que l'interrogateur a laissé entendre (oublié de fork et juste cloné localement un dépôt, apporté des modifications et maintenant besoin d'émettre une pull request), vous pouvez vous remettre sur les rails:
forkez le dépôt auquel vous souhaitez envoyer la pull request
transférez vos modifications locales sur votre télécommande
Une autre différence subtile étrange sur GitHub est que les modifications apportées aux fourchettes ne sont pas comptées dans votre journal d'activité tant que vos modifications ne sont pas intégrées dans le dépôt d'origine. De plus, pour changer un fork en un clone approprié, vous devez contacter le support Github, apparemment.
Les validations effectuées dans un fork ne seront pas prises en compte dans vos contributions. Pour les faire compter, vous devez effectuer l'une des opérations suivantes:
Ouvrez une demande d'extraction pour que vos modifications soient fusionnées dans le référentiel parent. Pour détacher le fork et le transformer en un référentiel autonome sur GitHub, contactez le support GitHub . Si la fourche possède ses propres fourches, indiquez au support si les fourchettes doivent se déplacer avec votre référentiel dans un nouveau réseau ou rester dans le réseau actuel. Pour plus d'informations, consultez « À propos des fourches ».
Réponses:
En gros, oui. A
forkest juste une demande à GitHub de cloner le projet et de l'enregistrer sous votre nom d'utilisateur ; GitHub garde également une trace de la relation entre les deux référentiels, afin que vous puissiez visualiser les commits et les pulls entre les deux projets (et d'autres forks).Vous pouvez toujours demander que les gens tirent de votre référentiel cloné, même si vous ne l'utilisez pas
fork, mais vous devrez vous occuper de le rendre public vous-même. Ou envoyez aux développeurs des correctifs (voirgit format-patch) qu'ils peuvent appliquer à leurs arbres.la source
git pull. Un fork prend plusieurs commandes. Et ce n'est pas surprenant, presque toutes les fourches que je regarde sont obsolètes. Les fourches sont comme le problème du référentiel Maven sur les stéroïdes. Au lieu d'un dépôt obsolète (Maven), il y en a des milliers (Git).git pullafin qu'il y ait encore une sorte de relation qui existe. Si vous avez cloné l'intégralité de la copie, elle repose sur votre propre machine locale et est déconnectée du dépôt d'origine.Lorsque vous dites que vous forkez un référentiel, vous créez essentiellement une copie du référentiel sous votre ID GitHub. Le point principal à noter ici est que toutes les modifications apportées au référentiel d'origine seront reflétées dans vos référentiels fourchus (vous devez récupérer et rebaser). Cependant, si vous apportez des modifications à votre référentiel forké , vous devrez créer explicitement une pull request vers le référentiel d' origine . Si votre demande d'extraction est approuvée par l'administrateur du référentiel d'origine , vos modifications seront validées / fusionnées avec la base de code d' origine existante . Jusque-là, vos modifications ne seront reflétées que dans la copie que vous avez fourchée .
En bref:
Le modèle Fork & Pull permet à quiconque de fork un référentiel existant et de pousser les modifications vers son fork personnel sans avoir besoin d'un accès au référentiel source. Les modifications doivent ensuite être extraites dans le référentiel source par le responsable du projet.
Notez qu'après avoir forgé, vous pouvez cloner votre référentiel (celui sous votre nom) localement sur votre machine. Apportez-y des modifications et transférez-le dans votre référentiel forké. Cependant, pour refléter vos modifications dans le référentiel d'origine, votre demande d'extraction doit être approuvée.
Quelques autres discussions intéressantes -
Les git forks sont-ils réellement des clones git?
Comment mettre à jour un référentiel fourchu GitHub?
la source
Vous pouvez vous engager sur votre repo en ligne (ou vous engager sur votre repo local, puis pousser vers votre repo en ligne), puis envoyer une pull request.
Le chef de projet peut l'accepter pour obtenir vos modifications dans sa version principale en ligne.
la source
Un clone est l'endroit où vous avez une duplication et une séparation appropriées entre deux versions (éventuellement différentes) d'un référentiel. Lorsqu'un dépôt est modifié, le nouveau contenu doit être copié activement dans l'autre dépôt à l'aide d'une commande push. Et les modifications de l'autre repo récupérées.
Lorsque vous forkez un dépôt, sur un serveur, il n'est pas nécessaire de dupliquer le contenu car les deux dépôts utiliseront le même contenu [objet fixe] de ce même serveur. L'astuce consiste à gérer les différents points de vue des utilisateurs afin que chaque utilisateur pense avoir une copie personnelle complète du dépôt. Les poussées et les récupérations entre les fourches mettent simplement à jour les pointeurs de l'utilisateur.
À un niveau inférieur, git fait la même chose en interne. Si vous avez trois fichiers différents, chacun contenant
Hello World, alors git `` fourche '' simplement sa copie unique de l'objet blob Hello World et l'offre à chacun des trois endroits selon les besoins.La possibilité de fork sur le serveur signifie que la grande allocation de stockage de Github n'est pas si grande en moyenne, car tout le monde partage le seul repo sous-jacent.
la source
En un mot, Forking est peut-être la même chose que "cloner sous votre ID / profil GitHub". Un fork est à tout moment meilleur qu'un clone, à quelques exceptions près, évidemment. Le référentiel forké est toujours surveillé / comparé au référentiel d'origine contrairement à un référentiel cloné. Cela vous permet de suivre les modifications, de lancer des demandes d'extraction et de synchroniser manuellement les modifications apportées dans le référentiel d'origine avec votre référentiel forké.
la source
Alors que la réponse de @ AniketThakur est très bonne. Personne n'a encore répondu à la question suivante.
Non. Si vous contribuez à un référentiel, vous pouvez: Créer un clone local. Créez une succursale locale. Ajoutez des commits à cette branche. Poussez la branche locale vers github (création d'une branche distante dans le processus). Faites une pull request demandant que cette branche soit fusionnée dans la branche principale (ou la branche de votre choix).
la source
Dans le cas où vous avez fait ce que l'interrogateur a laissé entendre (oublié de fork et juste cloné localement un dépôt, apporté des modifications et maintenant besoin d'émettre une pull request), vous pouvez vous remettre sur les rails:
la source
Une autre différence subtile étrange sur GitHub est que les modifications apportées aux fourchettes ne sont pas comptées dans votre journal d'activité tant que vos modifications ne sont pas intégrées dans le dépôt d'origine. De plus, pour changer un fork en un clone approprié, vous devez contacter le support Github, apparemment.
De Pourquoi mes contributions ne s'affichent-elles pas :
la source
En un mot, "fork" crée une copie du projet hébergé sur votre propre compte GitHub.
"Clone" utilise le logiciel git sur votre ordinateur pour télécharger le code source et l'intégralité de l'historique des versions sur cet ordinateur
la source