Cosa significano queste parole in Git: repository, fork, branch, clone, track?

130

Onestamente non sono chiaro sulla semantica qui. Riguardano le copie / varianti di un'unità codice + cronologia, ma in passato non sono sicuro di poterlo dire. Questa struttura logica è spiegata da qualche parte?

git branch clone

— Eric Anderson
fonte

5

Consiglierei di leggere i primi due capitoli del libro Pro Git ( progit.org/book ).

— ewall,

61

+1. Molti tutorial di Git mostrano come eseguire determinate attività senza spiegare cosa significano determinate parole o come funziona Git. Chiedere una risorsa che affronti questo argomento è una domanda legittima.

— Daniel Stutzbach,

14

Vorrei poter fare +1 sul commento di Daniel di più. Mentre il significato di alcuni dei termini (ad esempio repository) dovrebbe essere ovvio, la loro relazione non è sempre (branch vs. fork) e il significato reale è facilmente interpretato erroneamente da qualcuno abituato a un VCS centralizzato. Inoltre, guarda "cos'è un ramo?" Di Pro Git sezione: un utente di base vuole davvero sapere su BLOB e alberi o vuole solo sapere qualitativamente che cos'è un ramo?

— Cascabel,

1

@DanielStutzbach è possibile inviare commenti su cose che non sono chiare nel libro. (Non conosco la terminologia corretta per dirlo.) L'ho fatto, ho detto che il libro deve definire cosa sia un repository. Sono d'accordo che è abbastanza difficile ottenere materiale concettuale da persone che capiscono qualcosa molto bene. Quel libro (attualmente) parla di database senza definire cosa sono in questo contesto e non dice nulla su cosa siano i repository.

— user34660

146

Un repository è semplicemente un luogo in cui è archiviata la cronologia del tuo lavoro. Vive spesso in una .gitsottodirectory della tua copia di lavoro, una copia dello stato più recente dei file su cui stai lavorando.

Per biforcare un progetto (prendere la fonte dal repository di qualcuno in un determinato momento e applicare le proprie modifiche divergenti ad esso), clonare il repository remoto per crearne una copia, quindi fare il proprio lavoro nel proprio repository locale e commettere modifiche.

All'interno di un repository ci sono dei rami, che sono effettivamente fork nel proprio repository. Le tue filiali avranno un commit antenato nel tuo repository e divergeranno da tale commit con le tue modifiche. Successivamente puoi unire le modifiche alla tua filiale. I rami ti consentono di lavorare su più funzioni diverse contemporaneamente.

Puoi anche tenere traccia dei singoli rami nei repository remoti. Ciò ti consente di estrarre le modifiche dai rami di un'altra persona e di unirle in un ramo tutto tuo. Questo può essere utile se tu e un amico state lavorando insieme su una nuova funzione.

Ci sono molti grandi libri git online. Dai un'occhiata a ProGit e Git Magic per iniziare, così come i tutorial ufficiali e il libro della comunità.

— NFM
fonte

Ovviamente leggere i manuali e le esercitazioni F è fondamentale. Ma questo mi sembra un ottimo riassunto di tutto il materiale. Molto apprezzato!

— brasofilo,

Nota che puoi cambiare la tua directory di lavoro locale in un nuovo ramo ("git checkout <new_branch>"). In questo caso, i file della directory di lavoro locale sono SOSTITUITI dal contenuto del ramo in cui si sta passando. Ma non perdi il tuo lavoro: Git archivia tutte le modifiche ("git commit") apportate sul ramo precedente nel "database" di Git (cartella nascosta .git) e ti consentirà di ripristinare i tuoi file.

— KrisWebDev,

3

Penso che richieda una menzione speciale che storicamente, indipendentemente da quale VCS hai usato, il fork e il branching sono stati considerati due cose separate. La ramificazione è stata considerata un accordo favorevole e implicito tra gli sviluppatori. Il fork è stato più serio in quanto implicava che gli sviluppatori che stavano lavorando a un progetto non erano d'accordo su alcune cose e hanno deciso di separarsi. Le forcelle di successo sono state in genere riunite in un unico progetto dopo che entrambe le parti hanno raggiunto un accordo. Da allora, Git (e GitHub) hanno offuscato questi termini ed entrambi i termini rappresentano sostanzialmente la stessa idea ma in modi diversi.

— Redteam316,

Quindi un repository non contiene i file per il progetto? Dici un luogo in cui è memorizzata la storia del tuo lavoro . È tutto? Solo la cronologia dei file ma non i file stessi?

— user34660

13

Risponderò alla mia domanda con un RTFM.

Ma leggi questo bel manuale. Come dice l'autore:

“La conclusione che ne traggo è che puoi davvero usare Git solo se capisci come funziona Git. Memorizzare semplicemente quali comandi dovresti eseguire in quali orari funzionerà a breve termine, ma è solo questione di tempo prima che ti blocchi o, peggio ancora, rompa qualcosa.

“Sfortunatamente, la metà delle risorse esistenti su Git adotta proprio questo approccio: ti guidano attraverso quali comandi eseguire quando, e si aspettano che tu debba fare bene se imiti semplicemente quei comandi. L'altra metà analizza tutti i concetti, ma da quello che ho visto, spiegano Git in un modo che presume che tu capisca già come funziona Git. "

— Eric Anderson
fonte

Questa introduzione sembra essere stata spostata su sbf5.com/~cduan/technical/git . L'URL originale funziona ancora per ora.

— Eric Anderson,

1

Questo è vero nel contesto. Se devi essere produttivo immediatamente o semplicemente controllare il codice, va bene non avere una profonda comprensione di come funziona git. I tutorial vanno bene. È così che mi sono appassionato. Tuttavia, se o quando devi essere più avanzato come creare rami, fork, rebase e altre attività più avanzate, allora devi sapere come funziona git, specialmente se il tuo background è in un controllo centralizzato del codice sorgente.

— Phil

3

Questo GoogleTechTalk è una fantastica introduzione a Git per imparare cosa sta realmente accadendo dietro le quinte mentre impari anche la lingua. È stato dato da uno dei primi collaboratori di Git e ha tenuto questo discorso nel 2007 come un modo per introdurlo in Git. Se guardi questo discorso non solo saprai cos'è ogni parola, come repository, fork, branch, ecc., Ma saprai anche cosa sta accadendo dietro le quinte quando ognuna di queste è fatta, unita, ecc.

L'indirizzo è lungo ma molto istruttivo. Contrasta inoltre Git con altri sistemi di controllo della versione in modo da avere un'idea del perché Git è stato creato com'era e di quali vantaggi comparativi sia rispetto ad altri sistemi di controllo. Anche se il discorso è vecchio, è molto utile alzarsi e correre. Lo guarderei prima di saltare ai manuali. Le cose avranno molto più senso di conseguenza, credo.

— opaco
fonte