Ogni repository Git contiene quattro componenti:
Tutto ciò che dalla registrazione si impegna alla collaborazione distribuita ruota intorno a questi oggetti principali.
La directory di lavoro è dove effettivamente si modificano i file, si compila il codice e si sviluppa in altro modo il progetto. A tutti gli effetti, è possibile considerare la directory di lavoro come una normale cartella. Tranne che ora hai accesso a tutti i tipi di comandi che possono registrare, modificare e trasferire i contenuti di quella cartella.
L'area di staging è un intermediario tra la directory di lavoro e la cronologia del progetto. Invece di costringerti a impegnare tutte le tue modifiche contemporaneamente, Git ti consente di raggrupparle in changeset correlati. I cambiamenti di scena non fanno ancora parte della cronologia del progetto.
Una volta configurate le modifiche nell'area di gestione temporanea, è possibile eseguirne il commit nella cronologia del progetto in cui rimarrà una revisione "sicura". I commit sono "sicuri" nel senso che Git non li cambierà mai da solo, anche se è possibile tu per riscrivere manualmente la cronologia del progetto.
Finora, siamo ancora in grado di creare solo un lineare cronologia del progetto, aggiungendo un commit su un altro. Le filiali consentono di sviluppare più funzioni non correlate in parallelo, biforizzando la cronologia del progetto.
I rami Git non sono come i rami dei sistemi di controllo delle versioni centralizzati. Sono economici da realizzare, semplici da unire e facili da condividere, quindi gli sviluppatori di Git usano le filiali per qualunque cosa-dalle funzionalità di lunga durata con diversi contributori alle correzioni di 5 minuti. Molti sviluppatori solo lavorare in sezioni tematiche dedicate, lasciando il ramo della storia principale per le pubblicazioni pubbliche.
Questa lezione rappresenta un capitolo da Git in modo succinto, un eBook gratuito dal team di Syncfusion.