differenza tra fork e branch su github

Se fork un progetto che è ospitato su Github. Devo biforcare tutti i rami? Come faccio a sapere su quale ramo è basato il mio fork? In altre parole, quale ramo verrà scaricato sul mio PC?

Tutti i rami su GitHub verranno copiati in un fork. (Ovviamente, questo non include i rami che non sono mai stati inviati a GitHub in primo luogo.)

Ma un fork è un'operazione GitHub-to-GitHub; nulla viene copiato sul tuo PC. Non è esattamente lo stesso di un clone Git . Se intendi chiedere "cosa viene copiato quando clonare un progetto?", Consultare il manuale di git-clone(1).

Pensare in questo modo:

Il repository [sitory] corrisponde al lavoro collaborato del team attraverso una o più filiali. Tutti i collaboratori ne hanno una propria copia.

Ogni fork del repository principale corrisponde al lavoro di un collaboratore. Un fork è in realtà un costrutto Github (non Git) per archiviare un clone del repository nel tuo account utente. Come clone, conterrà tutti i rami nel repository principale nel momento in cui hai effettuato il fork.

Ogni ramo all'interno della forcella e / o nel repository principale può corrispondere a diversi tipi di cose, a seconda di come si desidera lavorare. Ogni ramo potrebbe fare riferimento a una versione del progetto ma può anche corrispondere a diversi canali di sviluppo, come hotfix o lavori sperimentali.

La richiesta pull (nell'ecosistema GitHub) corrisponde all'attività. Ogni volta che voglio contribuire con un task finito isolato al repository principale, creo una richiesta pull corrispondente ai commit effettuati in quel task. Questi commit vengono estratti dalla mia forcella o dal mio ramo nel repository principale .

Un commit è un insieme di modifiche al codice. Questa è una delle cose più interessanti di Git. Non trasferisci file, trasferisci i registri delle modifiche.

Fork è un clone sul lato GitHub (clona tutto).
Quando clonate un repository, ottenete tutta la storia di detto repository, con tutti i suoi rami.

Anche se in teoria è possibile modificare il ramo predefinito di un repository remoto , un clone di un repository GitHub cerca principalmente il ramo master. Il significato per modificare il ramo "predefinito" che otterrà un clone di GitHub, è necessario rinominare il ramo principale.

Se esegui il fork di un progetto, stai eseguendo una copia dell'intero progetto sul tuo account git hub. non stai copiando nulla sul tuo PC

Per fare una copia sul tuo PC devi clonarlo ed estrarre tutto il materiale e otterrai tutti i rami e il codice di quel progetto

Se si crea un fork di un progetto dal sito Web Github, si ottengono tutti i rami dal progetto a monte.

Se clonate dal fork appena coniato al PC locale, originil PC sul telecomando sarà puntato verso il ramo master del fork su Github.

Questo può essere spiegato molto bene. Hai un repository centrale su GitHub. Ogni volta che ne prendi un clone sul personal computer per apportare alcune modifiche, questo clone locale del repository principale viene chiamato fork.

Il ramo è qualcosa di diverso ed è incluso nel fork / repository. In realtà il ramo è il tuo lavoro in diverse fasi di sviluppo. Vengono creati come e quando richiesto per salvare una serie di funzionalità, per consentire l'accesso a diversi utenti, per dimostrare il sito al cliente, ecc.

Vorrei condividere un esempio di vita reale di quando usiamo Branches e quando usiamo Forks

Abbiamo GitLab nel nostro negozio e talvolta dobbiamo lavorare su pacchetti di un progetto Laravel. Normalmente creiamo un ramo e inviamo le modifiche al ramo che abbiamo testato nel nostro ambiente di sviluppo VM locale quando lavoriamo con il progetto Laravel attuale.

Supponiamo che il nostro progetto si trovi all'indirizzo

https://github.com/yardpenalty/mainproject.git

Utilizzo delle filiali:

Diciamo che si chiama il ramo It_doesnt_matter

Una volta che abbiamo la nostra filiale nel modo che desideriamo per la produzione, facciamo la nostra spinta finale verso questa filiale e creiamo una richiesta di unione che poi va in UAT per i test. Una volta che il test è passato attraverso il controllo qualità, le modifiche vengono unite nella produzione.

L' unione dal It_doesnt_matter ramo viene ora trasferita al progetto principale

a https://github.com/yardpenalty/mainproject.git

Diciamo che il progetto del pacchetto si trova in

https://github.com/yardpenalty/mypackage.git

Tieni presente che il progetto principale utilizza questo pacchetto in produzione, quindi non possiamo apportare modifiche semplicemente spingendolo a questo pacchetto (tra le altre ragioni). Supponiamo che uno sviluppatore web debba modificare questo pacchetto per apportare modifiche alla produzione.

Un ramo semplice non funzionerà neanche perché non possiamo vedere le nostre modifiche senza pubblicare il pacchetto ecc.

Uso della forcella: ora è quando dobbiamo fare un po 'di inganno con il nostro pacchetto in modo da creare un clone del pacchetto di produzione tramite una forcella. I file composer.json possono essere aggiornati in modo da puntare al fork che ora si trova in un percorso Utente o Gruppo

Quindi creeremo un fork https://github.com/yardpenalty/mypackage.git

e chiamalo https://github.com/yardpenalty/yards/mypackage.git

Ora possiamo aggiornare il nostro file composer.json per puntare a questo pacchetto nei nostri "repository": [array come tale e via!

 {
            "type": "github",
            "url": "https://github.com/yardpenalty/yard/mypackage.git"
 }

]