Confronto e contrasto tra repository locali e remoti
Git è un sistema distribuito in cui il codice sorgente si trova nel computer di ciascun sviluppatore. Ciò include la cronologia completa di tutti i commit effettuati sul progetto. Un sistema di questo tipo è noto come repository locale.
In questo modo, lo sviluppatore può lavorare nel proprio ambiente isolato senza timore che qualcuno alteri il codice mentre sta ancora sviluppando una funzionalità. Inoltre consente di confrontare il codice con le versioni precedenti, eseguirne il rollback, unirlo e così via. È persino possibile eseguire tutte queste operazioni senza una connessione di rete.
La maggior parte delle attività svolte da uno sviluppatore in Git avviene su un repository locale. Git supporta e agevola la diramazione, il cui concetto sarà discusso in un modulo separato. In ogni caso, anche la maggior parte dei rami viene creata su un repository locale.
In una fase successiva, diventa necessario condividere le modifiche apportate o le nuove funzionalità create con il team di sviluppo. Per tale motivo in Git si usa un repository remoto. Un repository locale può essere collegato anche a più repository remoti, se necessario. Il repository remoto viene usato per condividere facilmente il codice con gli altri membri del team, ma anche per configurare le pipeline di build. Queste pipeline compilano il codice di cui viene eseguito il push al repository remoto. Un push può consistere nel trigger che avvia la pipeline.
Repository locale
È possibile distinguere il repository locale in tre diverse aree o directory.
Directory di lavoro: è un singolo checkout di una versione del codice. La directory di lavoro contiene il codice con cui si sta lavorando. È possibile modificare i file tramite il comando checkout. Ogni volta che si modifica il ramo di lavoro attivo, i file nella directory di lavoro vengono modificati per assimilarli alla specifica versione di codice. I file visibili in Esplora risorse sono i file contenuti nella directory di lavoro.
Area di gestione temporanea: funge da area intermedia tra la directory di lavoro e la directory Git. Prima di eseguire il commit di un file dalla directory di lavoro alla directory Git, è necessario prepararlo per il commit. Il file viene quindi contrassegnato, nello stato in cui si trova, per il commit successivo. È possibile continuare a lavorare con il file. Tutte le modifiche apportate al file che non sono state preparate per il commit non verranno aggiunte con il commit successivo. Solo il contenuto del file preparato per il commit verrà aggiunto. Questo approccio è utile quando si sta lavorando a una funzionalità e non la si è ancora completata. È possibile preparare le modifiche per il commit e continuare a lavorare. Se si deve eseguire il commit a fine giornata, sarà comunque possibile farlo per una versione funzionante, rappresentata dalla versione dall'area di gestione temporanea, senza il rischio di eseguire il commit di un file non del tutto sviluppato.
Directory Git: contiene tutti i metadati e il database degli oggetti. Ogni file che si invia a Git viene archiviato in questa directory. Se si abilita l'opzione per visualizzare gli elementi nascosti in Esplora risorse, si vedrà una cartella .git. Questa cartella contiene sottocartelle al cui interno si trovano gli oggetti, nonché informazioni sul puntatore. Se si elimina questa cartella, viene eliminato anche il repository Git locale. Si tratta di una caratteristica che, allo stesso tempo, permette di copiare l'intero repository locale su un'unità USB per usarlo su altri computer. È essenziale non alterare questa directory per evitare il danneggiamento del repository locale. Questa è anche la directory che si usa per la sincronizzazione con il repository remoto.
Quando si usa questa configurazione, un file all'interno di Git può trovarsi in una tra le seguenti tre fasi.
Non modificato e archiviato nella directory Git: viene eseguito il commit del file.
Modificato e nell'area di gestione temporanea: il file viene preparato per il commit.
Modificato e non nell'area di gestione temporanea: il file viene modificato.
Ciclo di vita dei file Git
Lo schema successivo mostra il ciclo di vita completo di un file. La prima volta che un nuovo file viene creato o aggiunto a una cartella all'interno di Esplora risorse, assume lo stato untracked. Il file non è ancora entrato nel ciclo di vita Git. Usare il comando add per aggiungere questo file all'area di gestione temporanea, dove verrà approntato. In un secondo momento è possibile usare il comando commit per aggiungere il file nella directory Git. Quindi, il file assumerà lo stato unmodified. Ogni volta che si modifica un file, questo assume lo stato modified oppure untracked quando lo si rimuove dalla directory Git. Per rimuovere un file si usa il comando rm. La rimozione di un file dalla directory Git non comporta la sua eliminazione dal disco. Questa è un'operazione che lo sviluppatore deve eseguire manualmente.
Repository remoto
Il repository remoto si usa tramite i comandi push e pull per la sincronizzazione con il repository locale. Pertanto, anche quando si sta condividendo codice o ricevendo aggiornamenti dal team, le operazioni vengono eseguite da comandi che aggiornano il repository locale. Poiché ogni repository è autonomo, il relativo proprietario è tenuto a mantenerlo aggiornato alle modifiche apportate da altri.
Lo schema successivo mostra due sviluppatori che usano il repository remoto per condividere modifiche. Lo sviluppatore A sta effettuando il commit delle modifiche nel repository locale e usa il comando push per caricare le modifiche nel repository remoto. Lo sviluppatore B può usare il comando pull per scaricare le modifiche e può eseguire il push delle modifiche.
