Registrare i Cambiamenti nel Repository

Ogni file nella tua directory di lavoro è in una dei due stati seguenti: tracciato o non tracciato. I file tracciati sono i file presenti nell'ultimo snapshot; possono essere non modificati, modificati o staged (parcheggiati).

I file non tracciati sono tutti gli altri - qualsiasi file nella tua directory di lavoro che non è presente nel tuo ultimo snapshot o nella tua area di stage.

Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché li hai appena prelevati e non hai modificato ancora niente.

Quando modifichi i file, Git li vede come cambiati, perché li hai modificati rispetto all'ultimo commit. Parcheggi questi file e poi esegui il commit di tutti i cambiamenti presenti nell'area di stage, ed il ciclo si ripete.

Il ciclo di vita dello stato dei tuoi file.

Utilizzo dell'area di Stage

Mettere i file nello stato Stage può essere utile per avere successivi snapshot di un file, senza per forza procedere ad un commit. Si possono poi utilizzare questi snapshot per riportare il file al suo stato in uno qualsiasi di questi.

NOTA: l'utilizzo dello staging non è comunque obbligatorio, essendo consentito anche solo il commit, senza per forza passare dall'area di staging.

Quando si modifica un file precedentemente committato, Git ci segnala che un file tracciato è stato modificato nella directory di lavoro ma non ancora messo in stage.

In Eclipse, la vista Staging, raggiungibile tramite Window → Show View → Other... → Git → Git Staging fornisce una comoda panoramica su tutte le modifiche che avete fatto da quando si è fatto il check out di un ramo.

In questa vista si selezionano tutti i file che sono stati modificati e si possono trascinare nella zona Staged. Per aggiungere un file all'area di stage, si può anche scegliere l'opzione Add To Index. Per confermare le modifiche messe in scena si scrive un messaggio di commit descrittivo e premere il pulsante Conferma che viene evidenziato nello screenshot seguente.