Come accennato, Git è un ottimo alleato sia per il lavoro del developer singolo che per la cooperazione di team di web developers.
Vediamo adesso i 5 comandi principali che utilizzerà lo sviluppatore individuale e alcune loro argomentazioni.
- creare una nuova directory in Git
mkdir primo-progetto
- entrare nella directory in Git
cd primo-progetto
- inizializzare il repository Git nella cartella
$ git init . Initialized empty Git repository in /home/developer/primo-progetto/.git/
- creare un file vuoto in Git
touch README.md
- aggiungere il file a quelli inclusi nel repository in Git
git add README.md
- salvare la prima versione del file nel repository in Git
$ git commit -m "creato file vuoto read me" [master (root-commit) 776795e] creato file vuoto read me 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md
- vedere la storia del repository in Git:
$ git log commit 776795ecb7a9f0e5fd9eee1ae8b21b9ac06b3716 (HEAD -> master) Author: Luca Ferretti <elle.uca@gmail.com> Date: Tue Dec 6 00:26:55 2022 +0100 creato file vuoto read me
aprire il file README.md in un editor di testo, scrivere qualcosa e salvare il file
- visualizzare le modifiche tra l’ultima versione del repository e quella attualmente sul computer in Git
$ git diff diff --git a/README.md b/README.md index e69de29..41c99e9 100644 --- a/README.md +++ b/README.md @@ -0,0 +1,3 @@ +Hello, Git! +
- vedere lo stato del repository in Git
$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: README.md no changes added to commit (use "git add" and/or "git commit -a")
- aggiungere il file a quelli da includere nel prossimo set di modifiche da salvare nella cronologia delle modifiche in Git:
git add README.md
- salvare il nuovo set di modifiche in Git
$ git commit -m "primo contenuto del file read me" [master f0896d3] primo contenuto del file read me 1 file changed, 3 insertions(+)
- visualizzare la nuova cronologia, ma stavolta nel formato abbreviato:
$ git log --pretty=oneline --abbrev-commit f0896d3 (HEAD -> master) primo contenuto del file read me 776795e creato file vuoto read me
Complimenti, hai creato il tuo primo repository e usato i 5 comandi (e alcuni loro argomenti) che vi accompagneranno ogni giorno nel vostro viaggio assieme a Git.
Cosa abbiamo fatto?
Un po’ confuso? Tranquillo! Ti spieghiamo un po’ meglio cosa abbiamo fatto: la sequenza di comandi riportata nel precedente paragrafo ha compiuto le seguenti azioni:
- inizializzare un repository in Git – il comando git init crea un repository nella directory corrente; in pratica viene creata nella directory una sotto-directory nascosta .git in cui verranno salvati di volta in volta tutti i fine necessari a Git per conoscere la cronologia delle modifiche (history) e lo stato attuale;
- aggiunto un nuovo file al repository in Git – la prima sequenza dei comandi git add e git commit salva la nostra prima modifica alla history, tale modifica prende il nome di commit nel linguaggio di Git;
- salvata una modifica a un file già incluso nel repository in Git – con la seconda sequenza dei comandi git add e git commit si è salvato nella history un secondo commit, ovvero un secondo gruppo di modifiche di cui vogliamo tenere traccia;
- visualizzato lo stato del repository in Git – i comandi git status e git diff ci permettono di avere informazioni sullo stato attuale del repository, sulla eventuale presenza di modifiche a file aggiunti al repository, sulla presenza di file non gestiti ed altro;
- visualizzata la history del repository in Git – il comando git log permette di accedere alla cronologia dei commit eseguiti, con maggiore o minore dettaglio a seconda degli argomenti indicati
È importante notare subito un paio di caratteristiche di Git (o più in generale dei version control system):
- non tutto il contenuto di una directory è automaticamente aggiunto al repository: va esplicitamente indicato quali sono i file da includere; ciò risulta molto utile nel caso di progetti software, per i quali è naturale voler gestire l’evoluzione dei file sorgenti ed escludere invece i file “di build”
- non tutte le modifiche salvate ai file di un progetto sono automaticamente incluse nel commit: va esplicitamente indicato cosa includere nei singoli commit; ciò risulta utile per includere nel commit solo le modifiche rilevanti al fine di ricostruire l’evoluzione di un progetto, escludendo magari prove intermedie
- il workflow tipico di Git ruota attorno allo stato attuale dei file nella directory del repository (nuovi, rimossi, modificati) e al momento in cui si vuole fissare nella history un ben specifico stato
Di questa ultima annotazione parleremo più estesamente nella prossima sezione, andando a chiarire alcuni concetti fondanti di Git.