Ritorno a battere qualche riga sul blog dedicandomi alla stesura di un articolo su GIT e le sue fondamenta. Innanzitutto, se non hai idea di cosa parla questo articolo posso schiarirti le idee: GIT è un sistema di controllo di versione distribuito il quale software viene rilasciato in maniera open source.
L’idea di fondo è avere macchine in comunicazione tra loro in maniera distribuita, non c’è un server che si interfaccia con un client.
E’ possibile realizzare due tipi di repository: locale o remoto (GitHub o Bitbucket), entrambe le possibilità verranno delineate negli articoli successivi, oggi mi soffermo sulle basi per acquisire padronanza con questo meraviglioso sistema.
Quali conoscenze acquisirai dopo aver letto questo articolo?
- Padronanza di utilizzo di uno dei sistemi di versionamento più utilizzati al mondo;
- Gestire in maniera corretta un progetto;
- Miglioramento del team working;
- Rilasciare differenti versioni del software.
Repository locale
Come vedremo è possibile creare un repository locale e attraverso i branch mantenere una o più versioni del software. Questa tecnica è utilissima soprattutto se consideriamo di sviluppare una funzionalità del quale non siamo totalmente sicuri: creando un ramo (branch) git si preoccuperà di “duplicare” l’applicazione in un altro nodo e lasciare intatta quella di base in modo tale da poter effettuare tutti i test e le operazioni nel ramo appena creato. Appena siamo sicuri che la nuova funzionalità sia pronta e testata possiamo effettuare un merge sul branch master.
Questo schema chiarisce ogni tipo di dubbio sull’utilizzo corretto di GIT:
- Sul ramo master risiede l’applicazione testata e funzionante;
- Per implementare la funzionalità di login creo un nuovo branch;
- Dopo svariati test mi accorgo che la funzionalità di login è stabile e funzionante, effettuo un merge con il ramo master;
- Il ramo master conterrà l’applicazione stabile compresa di funzionalità di login da poco implementata;
- Creo un nuovo branch per l’applicazione di logout;
- Mi accorgo che ho combinato un bel pasticcio e l’applicazione va in crash! Niente paura, elimino il branch logout e torno sul ramo master dove mantengo l’applicazione stabile;
La teoria è abbastanza chiara, vero? Passiamo alla pratica.
1. Installare git
In questa guida impareremo ad utilizzare GIT da riga di comando, chi non ha dimestichezza con essa può sempre avvalersi di software desktop come TortoiseGit. In ogni caso consiglio di proseguire la lettura di questa guida poiché insegna le basi e i concetti fondamentali.
Installare GIT è molto semplice e veloce, attraverso l’indirizzo git-scm.com
2. Inizializzare un repository
Dopo aver installato GIT è necessario inizializzare il repository locale.
cd h:/Sites/progetto
all’interno della root utilizzeremo il comando init di git per iniziare un nuovo repository:
git init
Abbiamo un nuovo repository!
Per verificare l’effettivo stato del progetto è possibile utilizzare il comando status:
git status
3. Escludere file dal repository
Prima di iniziare col progetto facciamo un check dei file da escludere a priori come ad esempio i file di configurazione o le cartelle di progetto degli ambienti di sviluppo. Io ad esempio utilizzo NetBeans e ho necessità di escludere la cartella nbproject dal repository poiché non fa parte del progetto.
GitIgnore
Appena fatta l’init nella root del progetto verrà generato automaticamente un file chiamato .gitignore, solitamente nascosto, che conterrà su ogni riga i file e/o le cartelle da escludere. Segue un esempio di modifica del file .gitignore da riga di comando con vim (nulla vi vieta di poterlo creare in maniera standard).
vim .gitignore
premo I per entrare in modalità inserimento e digito:
nbproject/*
config.php
premo ESC per uscire dalla modalità inserimento e salvo con :wq
4. Comandi base
Entrati nel vivo della vostra applicazione avrete a che fare con una serie di comandi base che utilizzerete in routine:
Add
Questo comando precede la commit e serve a comunicare al repository quali file andremo ad aggiungere al progetto. Il comando è molto semplice:
git add .
Utilizziamo il punto per specificare al repository che siamo intenzionati ad aggiungere tutti i file presenti nella cartella in cui siamo posizionati da riga di comando e le sue sottocartelle.
Ovviamente è possibile specificare un solo file:
git add login.php
git add functions/work.php
O una sola cartella con tutto il suo contenuto:
git add folder/*
Commit
Per poter validare e indicizzare un file nel repository è necessario “committarsi” con quest’ultimo. La sintassi è semplice:
git commit -m "bug fix su pagina login"
Come vedete GIT preferisce ad ogni commit venga obbligatoriamente rilasciato un messaggio, in piena filosofia open source vi sarà utile per i progetti più corposi che coinvolgono più risorse. In questo modo ogni singola risorsa è consapevole del cambiamento.
Personalmente mi è capitato di riprendere un progetto a distanza di mesi e grazie ai messaggi nelle commit ho potuto riprendere padronanza del progetto senza tanta fatica.
Inviando una commit traccerete un punto sul ciclo di vita dell’applicazione. Più avanti vedremo perché è importante effettuare una commit appena siamo sicuri che il pezzo di codice funzioni correttamente.
5. Branch e Merge
Entriamo nel cuore di GIT:
Branch
Come spiegato precedentemente i branch sono un parte fondamentale in GIT, contribuiscono a rendere più lineare lo sviluppo di un’applicazione.
git checkout -b nome_branch
con questo semplice comando abbiamo creato un ramo all’interno della nostra applicazione.
Per eliminare un ramo:
git branch -d nome_ramo
Per passare da un ramo all’altro
git checkout nome_branch
esempio concreto (passare dal ramo corrente al ramo master)
git checkout master
Merge
Il comando per effettuare un merge fra due rami è molto semplice:
git merge nome_ramo
Esempio
Nella figura a sinistra (dettaglio della figura n°2 in alto) creo un nuovo ramo, appena completata la funzionalità nel ramo “login” effettuo un merge sul ramo master. Ecco un esempio completo:
git checkout login
git add .
git commit -m "completata funzionalità login"
git checkout master
git merge login
Non vi spaventate, nulla di più semplice: i primi tre comandi mi posizionano sul ramo “login”, aggiungono al repository i file modificati e li mandano in commit.
Gli ultimi due comandi servono a posizionarsi sul ramo principale (master) e ad effettuare il merge con il ramo login.
6. Ooops! Devo tornare indietro!
Può capitare spesso di voler ritornare indietro e prenderci l’ultima versione di un file o un’intera versione della applicazione prima di una commit. Paradossalmente più branch e commit mandiamo al repository più creiamo per GIT diverse release del nostro software. Avendo tanti punti fissi possiamo tornare indietro e riprenderci le varie versioni, ecco alcuni comandi:
| Comando | Specifica |
|---|---|
| git revert HEAD | annulla una commit appena eseguita |
| git log git checkout hash |
permettere di riprendere una specifica commit fatta in passato |
| git HEAD | unstage |
| git checkout master . | annulla le modifiche effettuate nel ramo master |
7. I Tag
Per raffinare l’utilizzo di GIT arrivano i tag. Essi permettono di marcare differenti release dell’applicazione nel tempo in modo tale da poter riprendere il codice da qualsiasi release vogliamo.
git tag 1.2.0 3a2f3a52fe
la sintassi indica la versione della nostra release (1.2.0) e l’id della commit che puoi ricavare attraverso il comando git log precedentemente illustrato.
git tag -l
questo comando permette di listare tutti i tag presenti nell’applicazione.
8. Conclusione
Imparare ad utilizzare correttamente GIT oggi vuol dire automaticamente migliorare il proprio ciclo produttivo. Nel prossimo articolo vedremo come interfacciare e configurare un repository remoto utilizzando ambienti consolidati come GitHub e BitBucket.
