Le forcelle Git sono in realtà cloni Git?

817

Continuo a sentire la gente dire che stanno biforcando il codice in Git. Git "fork" suona sospettosamente come il "clone" di Git oltre ad una volontà psicologica (insignificante) di rinunciare a future fusioni. Non c'è nessun comando fork in Git, giusto?

GitHub rende le forcelle un po 'più reali pinzando la corrispondenza su di essa. Cioè, premi il pulsante a forcella e in seguito, quando premi il pulsante di richiesta pull, il sistema è abbastanza intelligente da inviare un'e-mail al proprietario. Quindi, è un po 'una danza intorno alla proprietà e ai permessi del repository.

Si No? Qualche angoscia per GitHub che estende Git in questa direzione? O qualche voce di Git che assorbe la funzionalità?

— Brian
fonte

10

Sì, è solo un tipo di clone che viene tracciato dal database github.

— Paŭlo Ebermann,

15

GitHub non fa qualcosa di speciale per evitare di raddoppiare i requisiti di archiviazione (sui server di GitHub)?

— Keith Thompson,

18

Non ancora menzionato: l'eliminazione di un repository privato elimina tutte le sue forcelle. L'eliminazione di un repository pubblico mantiene le forche ma promuove un fork come nuovo repository principale. Se il tuo capo rende privato il tuo repository pubblico, rompe tutte le fork esistenti e non sarai in grado di effettuare richieste pull da loro al repository privato. help.github.com/articles/…

— Platone

Credo (senza prove dal momento che GitHub non ce lo mostra) che il meccanismo reale qui è "i supplenti" di Git. In altre parole, la forcella è un clone a specchio con --referenceusato. Il modo esatto in cui vengono gestiti i repository pubblici e le eliminazioni non è affatto chiaro (spostare le alternative al repository promosso scelto casualmente? Indicare tutte le forcelle verso qualche alternativa comune che non fa parte del fork originale?) Ma l'uso di alternative spiega vari comportamenti osservabili.

— Torek,

925

Fork , nel contesto di GitHub, non estende Git.
Consente solo il clone sul lato server.

Quando si clona un repository GitHub sulla workstation locale, non è possibile contribuire nuovamente al repository upstream a meno che non venga dichiarato esplicitamente come "contributore". Questo perché il tuo clone è un'istanza separata di quel progetto. Se vuoi contribuire al progetto, puoi usare il fork per farlo, nel modo seguente:

clonare quel repository GitHub sul tuo account GitHub (questa è la parte "fork" , un clone sul lato server)
contributo si impegna a quel repository GitHub (è nel tuo account GitHub, quindi hai tutto il diritto di spingerlo)
segnala qualsiasi contributo interessante al repository GitHub originale (ovvero la parte "pull request" mediante le modifiche apportate al proprio repository GitHub)

Controlla anche " Flusso di lavoro collaborativo di GitHub ".

Se si desidera mantenere un collegamento con il repository originale (chiamato anche upstream), è necessario aggiungere un riferimento remoto a tale repository originale.
Vedi " Qual è la differenza tra origin e upstream su GitHub? "

forcella e monte

E con Git 2.20 (Q4 2018) e altro, il recupero dalla forcella è più efficiente, con le isole delta .

— VonC
fonte

6

"Quando clonate un repository GitHub sulla vostra workstation locale, non potete contribuire al repository upstream a meno che non sia esplicitamente dichiarato come" contributore "." --- Non è vero con "biforcazione"? Spiega per favore.

— Chharvey,

61

@ TestSubject528491 no, con una forchetta, significa che si sta clonando il repo a monte il proprio repo sul lato server GitHub. Quindi puoi clonare localmente quel nuovo repository "fork" sul tuo computer e riproporlo liberamente, poiché sei il creatore e il proprietario di quel fork.

— VonC

9

Per me, il punto chiave è che non puoi inviare un PR dalla tua copia locale a meno che tu non sia dichiarato di essere un collaboratore . Sono così abituato a presentare PR dal mio repository locale, ma è perché sono sempre contrassegnato come collaboratore. Se ci pensate, per inviare un PR dovete inviare un ramo al repository remoto e quindi creare il PR. Immagino abbia senso se non vuoi che persone casuali creino filiali sul tuo repository. E che preferiresti che li rovinassero e inviassero le PR in quel modo.

— Adam Zerner,

Ho visto il secondo approccio remoto "a monte" altrove, ma non è più semplice passare direttamente da "GitHub - Original" a "GitHub - Fork"? Il secondo approccio remoto non sembrava funzionare nella mia configurazione di Eclipse ed eGit, non riuscendo a spingere nel mio repository "GitHub - Fork" (niente da spingere).

— William T. Mallard,

Non importa, il link alle informazioni qui mi ha dato un'idea. Come collaboratore ha senso passare da "GitHub - Original" a "GitHub - Fork", quindi da "- Fork" alla macchina locale, ma se sei il proprietario probabilmente vorrai estrarre direttamente dal mio "- Fork" prima di rivedere, eseguire i test, ecc. prima di premere su "- Originale".

— William T. Mallard,

135

Continuo a sentire la gente dire che stanno biforcando il codice in git. Git "fork" suona sospettosamente come git "clone" più un po '(insignificante) volontà psicologica di rinunciare a future fusioni. Non c'è nessun comando fork in git, giusto?

"Forking" è un concetto, non un comando specificamente supportato da qualsiasi sistema di controllo della versione.

Il tipo più semplice di biforcazione è sinonimo di ramificazione. Ogni volta che crei un ramo, indipendentemente dal tuo VCS, hai "biforcato". Queste forcelle sono di solito abbastanza facili da ricongiungere.

Il tipo di fork di cui stai parlando, in cui una parte separata prende una copia completa del codice e se ne va, si verifica necessariamente al di fuori del VCS in un sistema centralizzato come Subversion. Un VCS distribuito come Git ha un supporto molto migliore per il fork di tutto il codebase e l'avvio efficace di un nuovo progetto.

Git (non GitHub) supporta nativamente il "fork" di un intero repository (cioè clonandolo) in un paio di modi:

quando cloni, originviene creato per te un telecomando chiamato
di default tutti i rami del clone seguiranno i loro originequivalenti
recuperare e unire le modifiche dal progetto originale da cui hai effettuato la forchetta è banalmente facile

Git rende le modifiche apportate alla fonte del fork semplici come chiedere a qualcuno del progetto originale di estrarre da te o richiedere l'accesso in scrittura per inviare nuovamente le modifiche. Questa è la parte che GitHub semplifica e standardizza.

Qualche angoscia per Github che estende git in questa direzione? O qualche voce di git che assorbe la funzionalità?

Non c'è angoscia perché il tuo presupposto è sbagliato. GitHub "estende" la funzionalità di fork di Git con una bella interfaccia grafica e un modo standardizzato di inviare richieste pull, ma non aggiunge la funzionalità a Git. Il concetto di full-repo-forking è inserito nel controllo della versione distribuita a un livello fondamentale. Puoi abbandonare GitHub in qualsiasi momento e continuare a spingere / estrarre progetti che hai "biforcato".

— misero
fonte

6

Grazie per la tua eccellente risposta. Voglio solo chiarire, questo significa che, al di fuori del contesto di Github, potrei clonarne alcuni X projectsulla mia macchina. Se apporto modifiche nel mio locale e non ho accesso in scrittura all'origine, invierò un'email all'autore del progetto per richiedere un pull. Farà un telecomando chiamato Gideon che sarà un url per il mio clone locale, e può tirare, giusto?

— Gideon,

1

Se vuoi contribuire con le tue modifiche a un progetto puoi salvarle in file, ad es. Usando git format-patch e allegarle a una e-mail a qualcuno che ha quell'accesso in scrittura, oppure puoi ottenere il tuo hosting, spingi il tuo lavoro a quello e invia l'URL in un'e-mail, ad esempio usando il comando git request-pull. I repository sulle workstation di solito non sono direttamente accessibili online.

— bdsl

Ma sì, se la tua workstation risulta accessibile su Internet all'autore del progetto, puoi semplicemente inviare loro l'URL e loro possono aggiungerlo come telecomando e estrarlo.

— bdsl

1

Ri: angst, l'unica cosa per me è che non c'è nessun link o pulsante per fare clic per creare un pulsante di prospettiva pull-from-my-repo in cui GitHub ti dice che sei 50 commessi dietro. Nessun problema ora che so che stanno usando il termine "Pull Request" per includere anche le richieste di pull dall'upstream al tuo fork GitHub. Git è difficile.

— William T. Mallard,

80

Sì, fork è un clone. È emerso perché, non puoi inviare copie di altri senza il loro permesso . Ne fanno una copia per te ( fork ), dove avrai anche il permesso di scrivere.

In futuro, se l'attuale proprietario o altri utenti con un fork apprezzano le tue modifiche, possono ritirarlo nel proprio repository. In alternativa puoi inviare loro una "richiesta pull".

— ssapkota
fonte

Posso semplicemente clonare il repository sul mio computer locale, creare un ramo, quindi inviare una richiesta pull al proprietario originale? Sembra ridondante avere più copie di repository ospitate su GitHub, solo per facilitare gli aggiornamenti del codice.

— Casey,

4

@Casey Puoi inviare una richiesta pull solo tramite GitHub dallo stesso GitHub e puoi solo inviare una richiesta pull GitHub da un ramo esistente su GitHub. Se non si è un collaboratore del repository in questione, non è possibile creare un ramo da cui è possibile avviare una richiesta pull di GitHub. Niente ti impedisce di farlo via e-mail alla vecchia maniera, ma GitHub non ha alcun ruolo in questo.

— Beau Simensen,

2

@Casey, a motivo è che normalmente altri non hanno accesso URL alla tua workstation. GitHub forksignifica che esiste una copia del tuo lavoro sul server GitHub, a cui puoi pushe a cui altri hanno accesso URL in modo che possano pull. Il pull requestè solo un modo standard per ottenere l'URL per la vostra copia (su GitHub) a loro in modo che possano facilmente tirare nella loro repository.

— Jesse Chisholm,

Questa dovrebbe essere la risposta corretta / accettata, credo. Immagina un disastro in una scena in cui un team di 15-20 sviluppatori che crea filiali e spinge verso l'origine contro 15-20 sviluppatori che hanno la propria copia dello stesso repository e fanno il maggior numero di filiali e fanno cambiamenti e lo respingono. Quindi l'autore del repository originale può eseguire solo le modifiche che desidera.

— Kishor Pawar,

37

"Fork" in questo contesto significa "Crea una copia del loro codice in modo che io possa aggiungere le mie modifiche". Non c'è molto altro da dire. Ogni clone è essenzialmente una forcella e spetta all'originale decidere se estrarre le modifiche dalla forcella.

— Daenyth
fonte

2

In particolare: "Crea una copia del loro codice in on the GitHub servermodo da poter aggiungere le mie modifiche and others can have URL access to my version". La maggior parte delle stazioni di lavoro locali non offrono l'accesso agli URL per chiunque sia in grado di estrarre. Ma se spingi al tuo fork sul server, allora possono avere l'URL per il pull.

— Jesse Chisholm,

La domanda non riguarda il fork è in generale, ma il fork di GitHub in particolare.

— reinierpost,

26

La clonazione comporta la creazione di una copia del repository git su una macchina locale, mentre il fork è la clonazione del repository in un altro repository. La clonazione è solo per uso personale (anche se potrebbero verificarsi future fusioni), ma con il biforcazione si sta copiando e aprendo un nuovo possibile percorso di progetto

— Sam Johnson
fonte

11

Il forking viene eseguito quando si decide di contribuire a qualche progetto. Dovresti creare una copia dell'intero progetto insieme ai suoi registri cronologici. Questa copia viene creata interamente nel tuo repository e una volta apportate queste modifiche, emetti una richiesta pull. Ora spetta al proprietario della fonte accettare la tua richiesta pull e incorporare le modifiche nel codice originale.

Git clone è un comando effettivo che consente agli utenti di ottenere una copia del sorgente. git clone [URL] Questo dovrebbe creare una copia di [URL] nel proprio repository locale.

— aliasav
fonte

10

Penso che fork sia una copia di altri repository ma con la modifica del tuo account. ad esempio, se clonate direttamente altri repository localmente, l'origine dell'oggetto remoto sta ancora utilizzando l'account da cui clonate. Non puoi impegnare e contribuire con il tuo codice. È solo una pura copia di codici. Altrimenti, se si effettua il fork di un repository, verrà clonato il repository con l'aggiornamento delle impostazioni dell'account nel proprio account github. Quindi, clonando il repository nel contesto del proprio account, è possibile eseguire il commit dei codici.

— Daniel Shen
fonte

10

C'è un malinteso qui riguardo a cosa sia una "forchetta". Un fork non è in realtà altro che un insieme di rami per utente. Quando si spinge verso un fork, si spinge effettivamente nel repository originale, poiché quello è l'UNICO repository.

Puoi provarlo spingendo verso un fork, notando il commit e poi andando nel repository originale e usando l'ID commit, vedrai che il commit è "nel" repository originale.

Questo ha molto senso, ma è tutt'altro che ovvio (l'ho scoperto solo per caso di recente).

Quando John crea il repository SuperProject, ciò che sembra realmente accadere è che tutti i rami nel repository di origine vengono replicati con un nome come "John.master", "John.new_gui_project", ecc.

GitHub "nasconde" il "John". da noi e ci dà l'illusione di avere la nostra "copia" del repository su GitHub, ma noi non ne abbiamo e non ne abbiamo nemmeno bisogno.

Quindi il ramo "master" del mio fork in realtà si chiama "Korporal.master", ma l'interfaccia utente di GitHub non lo rivela mai, mostrandomi solo "master".

Questo è praticamente ciò che penso succeda sotto il cofano, comunque, basato su cose che ho fatto di recente e quando ci pensi, è un ottimo design.

Per questo motivo penso che sarebbe molto facile per Microsoft implementare le forcelle Git nella loro offerta di Visual Studio Team Services.

— Hugh
fonte

Caro Hugh, metà della tua risposta è in realtà errata: un fork è un clone di un intero repository da un account utente a un altro account utente, insieme a tutti i rami e la cronologia. Quando ti impegni al fork, non cambia nulla nel repository originale da cui hai biforcato. Ma oltre a questi pochi fraintendimenti da parte tua riguardo a cosa sia un "fork", ora ci sono alcune buone notizie: i servizi di Visual Studio Team includono ora una funzionalità "Fork". ;)

— Sorin Postelnicu,

1

@SorinPostelnicu fonte? Sono propenso a credere a Hugh qui a causa dell'esperienza personale delle forcelle che si comportano in modi che non sono coerenti con il fatto che sono un semplice clone del repository. Ad esempio, quando si elimina l'upstream, le forchette vengono eliminate (come è stato menzionato in un commento sulla domanda dell'OP) e talvolta l'upstream ha finito per fondere le cose nei rami delle mie forche quando si accetta una richiesta pull, senza che io faccia nulla.

— Patata

In effetti questo sembra essere il caso. Dopotutto sarebbe incredibilmente stupido per GitHub letteralmente git cloneun repository completamente nuovo (anche uno "nudo") ogni volta che qualcuno preme il pulsante "fork" - sarebbe un incredibile spreco di spazio di archiviazione e probabilmente anche un vettore di attacco .

— Greg A. Woods,

7

A parte il fatto che la clonazione è dal server alla tua macchina e che il fork sta eseguendo una copia sul server stesso, una differenza importante è che quando cloniamo, otteniamo effettivamente tutti i rami, le etichette, ecc.

Ma quando eseguiamo il fork, in realtà otteniamo solo i file correnti nel ramo master, nient'altro che quello. Ciò significa che non otteniamo gli altri rami, ecc.

Quindi, se devi unire nuovamente qualcosa al repository originale, si tratta di una fusione tra repository e avrà sicuramente bisogno di privilegi più elevati.

Fork non è un comando in Git; è solo un concetto che GitHub implementa. Ricorda che Git è stato progettato per funzionare in un ambiente peer-to-peer senza la necessità di sincronizzare elementi con qualsiasi copia master. Il server è solo un altro peer, ma lo consideriamo una copia master.

— Deepak GM
fonte

7

Eh? Una forchetta ottiene tutti i rami, anche se devi sapere dove cercare (suggerimento:) git branch -a.

— triplo il

3

In termini più semplici,

Quando dici che stai biforcando un repository, si sono fondamentalmente creando una copia del repository originale sotto il GitHub ID nel tuo account GitHub.

e

Quando dici di clonare un repository, stai creando una copia locale del repository originale nel tuo sistema (PC / laptop) direttamente senza averne una copia nel tuo account GitHub.

— anoNewb
fonte