Differenze tra le versioni di "Struttura Repository Git"
m |
|||
Riga 1: | Riga 1: | ||
Un repository Git è essenzialmente una cartella sul disco locale, contenente la '''working directory''' e la cartella '''metadata'''. | Un repository Git è essenzialmente una cartella sul disco locale, contenente la '''working directory''' e la cartella '''metadata'''. | ||
− | La cartella metadata, è una sottocartella con nome '''.git'''. | + | La cartella metadata (o directory di Git), è una sottocartella con nome '''.git'''.è dove Git salva i metadati e il database degli oggetti del tuo progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository da un altro computer. |
− | La '''working directory''' | + | La '''working directory''' (o directory di lavoro) è un checkout di una versione specifica del progetto. Questi file vengono estratti dal database compresso nella directory di Git, e salvati sul disco per essere usati o modificati. |
Un caso a parte è un repository '''bare''', ovvero un repository nel quale risiedono solo i metadata, senza le copie dei file sulle quali si lavora. | Un caso a parte è un repository '''bare''', ovvero un repository nel quale risiedono solo i metadata, senza le copie dei file sulle quali si lavora. | ||
Riga 22: | Riga 22: | ||
# modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. | # modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. | ||
# staged significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit. | # staged significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit. | ||
+ | |||
+ | L'area di stage è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti la tua prossima commit. A volte viene indicato anche come 'indice', ma lo standard è definirlo come 'area di stage' (area di sosta, ndt | ||
Versione delle 17:22, 7 apr 2014
Un repository Git è essenzialmente una cartella sul disco locale, contenente la working directory e la cartella metadata.
La cartella metadata (o directory di Git), è una sottocartella con nome .git.è dove Git salva i metadati e il database degli oggetti del tuo progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository da un altro computer.
La working directory (o directory di lavoro) è un checkout di una versione specifica del progetto. Questi file vengono estratti dal database compresso nella directory di Git, e salvati sul disco per essere usati o modificati.
Un caso a parte è un repository bare, ovvero un repository nel quale risiedono solo i metadata, senza le copie dei file sulle quali si lavora.
Ambiente di lavoro
La tua copia locale del repository è composta da tre "alberi" mantenuti da git
- Working dir o directory di lavoro che contiene i file appartenenti alla versione corrente del progetto sulla quale l’utente sta lavorando.
- Index o Stage che contiene i file in transito, cioè quelli candidati ad essere committati.
- Head che contiene gli ultimi file committati.
I tuoi file in Git possono essere in tre stati: committed, modified e staged.
- committato significa che il file è al sicuro nel database locale.
- modificato significa che il file è stato modificato, ma non è ancora stato committato nel database.
- staged significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit.
L'area di stage è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti la tua prossima commit. A volte viene indicato anche come 'indice', ma lo standard è definirlo come 'area di stage' (area di sosta, ndt
Branching
I branch ('ramificazioni') sono utilizzati per sviluppare features che sono isolate l'una dall'altra. Il branch master è quello di default quando crei un repository.
Puoi usare altri branch per lo sviluppo ed infine incorporarli ('merge') nel master branch una volta completati.