Un repository può essere pensato come un archivio di tutte le modifiche apportate ai file di un progetto. Contiene non solo la versione attuale, ma anche tutte le versioni precedenti e i branch di sviluppo.
In questo articolo verranno illustrati i principali metodi per ottenere un repository Git locale.
- Inizializzazione di un repository locale: trasformare una directory già esistente, non ancora gestita da un sistema di versionamento, in un repository Git.
- Clonazione di un repository remoto: scaricare una copia completa di un repository Git già esistente, ad esempio ospitato su piattaforme come GitHub, GitLab o Bitbucket.
In entrambi i casi, al termine dell’operazione si dispone di un repository Git completamente funzionante sul proprio sistema Windows.
• Staging Area (git add): Prima di salvare le modifiche in un commit, è necessario dire a Git quali modifiche includere. Questo si fa trasferendo i file modificati (o nuovi) nella "staging area" (anche chiamata "indice").
git add nomefile.txt
git add . (per aggiungere tutti i file modificati nella directory corrente)
• Commit (git commit): Un commit è un'istantanea ("snapshot") dello stato del progetto in un determinato momento. Ogni commit rappresenta idealmente una singola modifica concettuale. I commit sono collegati tra loro in una "catena", che rappresenta la storia del repository.
git commit -m "Messaggio descrittivo del commit"
Il messaggio è molto importante e la prima riga viene usata come titolo in molte visualizzazioni. Dovrebbero essere concisi (prima riga preferibilmente <50 caratteri) e descrivere chiaramente le modifiche. La seconda riga può rimanere vuota, e dalla terza in poi possono seguire maggiori dettagli. Possono includere riferimenti a problemi (issues) e pull request.
• Stato del repository (git status): Permette di vedere quali file sono stati modificati, quali sono nella staging area e quali non sono tracciati.
git status
• Sincronizzazione con repository remoti:
- git push: Invia i commit dal repository locale a quello remoto.
git push origin main - git pull: Scarica le modifiche dal repository remoto e le integra nel repository locale.
git pull - git fetch: Scarica le modifiche dal repository remoto ma non le integra automaticamente nel repository locale.
• Branching (concetto base): Il branching è una funzionalità chiave di Git che permette di divergere dalla linea di sviluppo principale e lavorare su modifiche senza influenzare il codice stabile. I branch sono essenzialmente puntatori a un commit. Sebbene la gestione avanzata dei branch sia complessa, i principi di base sono essenziali per iniziare.
git checkout -b nome-nuovo-branch (crea un nuovo branch e ci si sposta)
• Visualizzazione della cronologia (git log): Mostra una lista dei commit, con il più recente in cima. È uno strumento potente per ripercorrere la storia del progetto.
git log
1. Inizializzare di un Repository locale
Se si possiede già una cartella di progetto che non è attualmente gestita da Git, è possibile convertirla in un repository locale.
Per farlo, è necessario aprire il Prompt dei Comandi o PowerShell e spostarsi nella directory desiderata.
cd C:/Projects/my_project
Una volta posizionati nella cartella del progetto, è sufficiente digitare:
git init
 |
| FIG 1 - Git init |
 |
| FIG 2 - Directory .git |
1.1 Aggiungere e Versionare i File
Per iniziare a gestire i file già presenti nella directory, occorre eseguirne il tracciamento. Ad esempio:
git add Readme.txt
Il comando git add permette di selezionare i file da includere nella prossima revisione. Una volta aggiunti, è possibile creare il primo commit:
git commit -m "Versione iniziale del progetto"
Questo passaggio registra ufficialmente lo stato iniziale del progetto nella cronologia di Git.
 |
| FIG 3 - Git add e commit |
2. Clonazione di un repository remoto
La seconda modalità per ottenere un repository consiste nella clonazione di un progetto già esistente.
A differenza di altri sistemi di versionamento centralizzati (ad esempio Subversion), Git non scarica solo una copia superficiale del progetto, bensì l’intera cronologia e la struttura interna del repository. Questo significa che ogni clone è, a tutti gli effetti, un repository completo e indipendente.
Il comando da utilizzare è:
git clone <url>
Supponiamo di voler clonare il noto editor Notepad++ direttamente da GitHub. È sufficiente digitare:
git clone https://github.com/notepad-plus-plus/notepad-plus-plus.git
- crea una cartella denominata notepad-plus-plus;
- inizializza al suo interno una directory .git;
- scarica tutti i dati del repository remoto;
- prepara automaticamente una copia di lavoro dell’ultima versione disponibile.
 |
| FIG 4 - git clone |
git clone https://github.com/notepad-plus-plus/notepad-plus-plus.git progetto1
In questo caso, i file del repository verranno copiati all’interno della directory progetto1.
Protocolli di Trasferimento Supportati
Git consente la clonazione e l’interazione con i repository remoti tramite diversi protocolli, ciascuno con specifici vantaggi e svantaggi:
- HTTPS: semplice da configurare e adatto a qualsiasi contesto, richiede spesso l’inserimento delle credenziali.
- SSH: più sicuro ed efficiente, consigliato per ambienti professionali; necessita la configurazione di una coppia di chiavi pubblica/privata.
- Git protocol (git://): veloce ma meno sicuro, usato raramente nei progetti moderni.
Registrare le modifiche nel repository
A questo punto si dispone di un vero e proprio repository Git locale, completo di una working copy contenente tutti i file del progetto. Da qui in avanti, l’attività tipica consiste nell’apportare modifiche e nel registrarne periodicamente lo stato mediante commit, creando così delle “istantanee” dell’evoluzione del progetto ogni volta che si raggiunge una condizione significativa.
È fondamentale comprendere che ciascun file presente nella directory di lavoro può trovarsi in uno dei seguenti stati: Tracciato (tracked) o Non tracciato (untracked).
- File tracciati (tracked): tutti i file presenti nell’ultimo commit, oltre a quelli che sono stati aggiunti all’area di staging. Essi possono trovarsi in tre condizioni differenti: non modificati, modificati o staged (pronti per il commit). In altre parole, sono i file di cui Git è a conoscenza e che gestisce attivamente.
- File non tracciati (untracked): tutti i file che si trovano nella directory di lavoro ma che non erano presenti nell’ultimo commit e non sono stati aggiunti allo staging.
Quando si clona un repository per la prima volta, tutti i file risultano tracciati e non modificati, poiché Git li ha appena copiati dal commit più recente.
Nel momento in cui si inizia a modificarli, Git rileva tali cambiamenti e li contrassegna come modificati. A questo punto, lo sviluppatore può decidere quali di essi inserire selettivamente nell’area di staging e, successivamente, consolidare tali modifiche in un nuovo commit. Questo processo – modifica, staging, commit – costituisce il ciclo fondamentale del lavoro quotidiano con Git.
Il Ciclo di Lavoro: Modifica, Staging e Commit
Il flusso di lavoro tipico con Git prevede una sequenza ricorrente di tre fasi:
- Modifica dei file nella working directory. Una volta che si cambia un file già tracciato, Git lo riconosce come modificato.
- Aggiunta allo staging delle modifiche rilevanti. Questo passaggio permette di selezionare quali modifiche includere nel prossimo commit. Ad esempio:
git add nome_file.ext
oppure, per aggiungere tutti i file modificati
git add . - Creazione di un commit. Il commit rappresenta una vera e propria "fotografia" dello stato dei file in staging. È buona prassi accompagnare il commit con un messaggio descrittivo:
git commit -m "Descrizione delle modifiche effettuate"
Questo ciclo si ripete ogni volta che il progetto raggiunge uno stato che si desidera salvare nella cronologia.
Nessun commento:
Posta un commento
I messaggi sono soggetti a moderazione da parte dell'amministratore prima della loro pubblicazione.