Share
Git è diventato il sistema più utilizzato per il controllo delle versioni e il codice di condivisione. Se vuoi aiutare a creare software open source, o se vuoi lavorare in un team di professionisti, comprendere Git è un must.
In una serie di corsi Git su Envato Tuts +, ho spiegato alcuni dei concetti fondamentali di Git, tutti illustrati con animazioni utili.
In questo video, imparerai a conoscere i tre alberi: HEAD, l'indice e la directory di lavoro. Guarda come spiego il ruolo di ognuno e come interagiscono man mano che aggiorni e esegui il commit del codice.
Per capire meglio come funziona Git, possiamo usare la metafora dei tre alberi. Questi alberi sono diverse raccolte di file.
Per il flusso di lavoro di aggiunta e recupero di commit, Git utilizza tre diverse versioni di file:
Ognuno di questi alberi ha un lavoro diverso: un albero per scrivere i cambiamenti, un albero per metterli in scena e uno per puntare al tuo ultimo commit su un ramo nel tuo repository Git.
I file il cui contenuto può essere modificato si trovano nella directory di lavoro. I file inseriti nel tuo indice si preparano a essere impacchettati in un oggetto commit. Questi commit sono salvati nel tuo repository Git.
I file che sono già stati impegnati sono file compressi. Sono sottoposti a hash tramite SHA-1, una funzione hash crittografica. Entrambe le versioni dei file nell'indice e il commit stesso vengono salvate nel repository Git, che è semplicemente una .git rectory al livello root del tuo wrap.
La directory di lavoro rappresenta i file effettivi sul file system del tuo computer che sono disponibili all'editor di codice per applicare le modifiche. La directory di lavoro è una versione di un particolare commit, una particolare istantanea di un progetto che hai estratto. È la versione della cronologia Git a cui HEAD punta, in qualsiasi momento.
"Estratto" significa che hai le versioni decompresse dei file estratti dal tuo repository Git, disponibili per la modifica. L'indice rappresenta ciò che viene monitorato. Potresti anche dire che è un elenco di tutti i file rilevanti per il tuo repository Git.
L'indice passa da un paio di nomi. Quando le persone parlano dell'area di staging, dei file di staging, della cache o della cache di directory, stanno tutti parlando dell'indice. Puoi vedere l'indice come zona di bozza per il tuo prossimo commit, un'area temporanea per preparare il prossimo commit.
HEAD è la parte di git che punta ai tuoi rami, come il ramo master di default. È un riferimento e ha un lavoro piuttosto semplice ma estremamente importante. HEAD punta al ramo attualmente estratto e, a sua volta, punta all'ultima commit da quel ramo. HEAD può muoversi non solo nel tempo (quando controlli i commit precedenti), ma si muove anche quando crei nuovi rami o semplicemente passa ad altri rami.
È anche il punto della tua storia Git che puoi mettere il tuo prossimo impegno su, il genitore per il prossimo commit. Con ogni nuovo commit, sostituisce il suo riferimento al ramo attualmente selezionato, di default, il ramo master, ovviamente.
Quindi, in effetti, HEAD è un riferimento che cambia frequentemente e punta a due cose: il ramo stesso e, attraverso questo, l'ultimo commit su quel ramo.
Diamo uno sguardo più da vicino al flusso di lavoro relativo alla gestione dei file in Git. È essenziale capire come tutti questi pezzi combaciano. Dopodiché avrai molto più tempo per dare un senso alle funzionalità e ai concetti più avanzati in Git.
Ecco un esempio:
In questo esempio, abbiamo impegnato due versioni del nostro file. E puoi vedere che le versioni nel repository, l'indice e la directory di lavoro sono la stessa cosa. Poiché questi file sono già tracciati, Git noterà eventuali differenze quando si modifica uno di questi file tracciati nella directory di lavoro.
Quando esegui il stato git comando, vedrai un elenco di file che sono stati modificati, colorati in rosso. Questo indica che ci sono delle differenze tra la tua directory di lavoro, rappresentata dal codice nel tuo editor di codice, e il tuo indice, che rappresenta le versioni dei file da un particolare commit, più comunemente l'ultimo commit.
Ora puoi eseguire il aggiungi git comando per mettere queste modifiche dalla directory di lavoro nell'indice in cui hai messo in scena i file. stato git mostrerà quindi i file che vengono aggiunti all'indice colorati in verde. Ciò significa che le tue modifiche sono pronte per essere impacchettate in un nuovo commit, su cui HEAD può puntare e costruire.
Un elenco di file verdi indica semplicemente che le versioni dei file di staging nell'indice sono diverse dalle versioni di file che erano già stati precedentemente impegnati. Quando corri Git commit, questi file staged verranno inseriti in un nuovo oggetto commit. Il Git commit comando salverà i nomi dei file effettivi, i contenuti di ciascun file, le informazioni dell'autore, i metadati e simili, in un nuovo oggetto.
Questo oggetto commit, che ora vive in a .idiota directory nel repository, sarà il nuovo riferimento a cui HEAD punta. Punta ai precedenti commit, essendo la punta dell'iceberg in un certo senso. Dopo aver creato il nostro oggetto commit, siamo tornati all'inizio del ciclo.
Il commit a cui punta HEAD nel repository è di nuovo corrispondente alle versioni nell'indice e alla directory di lavoro, che è pronta per le nuove modifiche da mettere in scena e commettere. Fine della storia.
Se hai trovato questo utile, perché non controllare alcuni altri corsi Git?
Puoi guardare la nostra introduzione a Git e GitHub o provare gli altri corsi di pausa caffè in questa serie:
Accentsconagua