Guide galattiche per aspiranti programmatori

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 Gi

  cd primo-progetto

   

• inizializzare il repository Git nella cartella

  $ git init .
  Initialized empty Git repository in /home/developer/primo-progetto/.git/

• crere 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.