GIT – guida all’utilizzo di un repository locale

GIT – guida all’utilizzo di un repository locale

5980
13
CONDIVIDI

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.

Niente di nuovo quindi, GIT è un svn. NO! Git non è un svn ma agisce in maniera distribuita anziché piramidale.
Ogni macchina è un repository

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.

Il ramo master è il branch principale dove ha vita l’applicazione stabile e funzionante.
Ciclo di vita di un progetto su GIT

Questo schema chiarisce ogni tipo di dubbio sull’utilizzo corretto di GIT:

  1. Sul ramo master risiede l’applicazione testata e funzionante;
  2. Per implementare la funzionalità di login creo un nuovo branch;
  3. Dopo svariati test mi accorgo che la funzionalità di login è stabile e funzionante, effettuo un merge con il ramo master;
  4. Il ramo master conterrà l’applicazione stabile compresa di funzionalità di login da poco implementata;
  5. Creo un nuovo branch per l’applicazione di logout;
  6. 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

Installa GIT

2. Inizializzare un repository

Dopo aver installato GIT è necessario inizializzare il repository locale.

Tutte le operazioni effettuate da terminale prevedono il posizionamento sulla cartella del progetto, prima di inizializzare un repository assicurarsi di essere posizionati nella root di progetto. Questo concetto lo assumiamo per default durante tutto il corso di questa guida:
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.

N.B. potete sempre aiutarvi con il comando git status per conoscere lo stato del repository ed il ramo corrente.

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.

Recensioni
Autore
Maurizio
Data
Articolo
GIT – guida all’utilizzo di un repository locale
Voto
5
  • Patrizio Liaci

    Confermo le tue conclusioni. Da quando utilizzo GIT la produttività è migliorata di molto. Senza considerare che è una skill in più molto importante.

  • DeepBlue

    Articolo molto esauriente!!! Aspettiamo una guida su git da remotooo!!!!!

  • fabio conchiglia

    ottimo articolo Mario, salvo nei preferiti 😉

  • Francesco s.

    Sarebbe anche utile capire come funziona github…ormai lo usano tutti…

  • Usiamo GIT da parecchi mesi ed abbiamo anche implementato un server GIT utilissimo per la condivisione di repository con colleghi e collaboratori.
    GIT è fantastico, e ricordate che potete navigare all’interno dei vostri repo via web anche in locale grazie a git-instaweb !!!

    Ciao e a presto,
    Fabio

  • Gianluca C

    Ciao, grazie per l’articolo. Molto interessante ed esauriente. Volevo chiederti alcune cose circa il tuo esempio in cui sviluppi un sito ed aggiungi le funzionalità, come ad esempio il login utilizzando i branch; se ho capito bene sul ramo master “giace” il codice che è stato approvato per la produzione e quindi ipoteticamente coincide con quanto risiede nella web root di apache. Quando si crea un nuovo branch, il codice che viene incluso nei vari commit del branch stesso non sarà incluso nel ramo master e, quindi, non sarà nella webroot finchè non si effettuerà il merge. Come si effettua il test di tale codice (ipotizziamo PHP) se esso non è incluso nella webroot di Apache?
    Scusa la domanda, che sarà di certo banale, ma sono proprio agli inizi con Git.

    Ciao grazie ancora.

    • Ciao Gianluca,
      quando effettui un checkout da un branch all’altro, il codice e le pagine vengono automaticamente “switchate”.
      E’ un’operazione che avviene dinamicamente e non devi preoccuparti di duplicare codici o versioni.
      Il bello è questo :)

  • Giacomo

    Ciao Mario, grazie per l’articolo, anche io sto approfondendo l’uso di GIT.
    Ho più o meno gli stessi dubbi di Gianluca C.
    Sempre riferendomi a tuo esempio di un branch “master” e un branch “login” vorrei capire quale flusso esattamente si segue anche in locale e sul server.
    Io ho capito così:
    partiamo dal fatto che ho il mio progetto in locale sincronizzato con quello sul server e ovviamente con il branch “master”.
    Devo iniziare a sviluppare il login, che faccio?

    1) creo il branch “login” nella repo
    2) lavoro in locale, testo tutto. Funziona
    3) committo sul branch “login”
    4) Effettuo un merge tra i due branch
    5) pubblico i file locali sul server live

    E’ corretto? Se ad esempio invece nel punto due combino un disastro, posso buttare tutto e clonarmi la master così da ritrovarmi con la versione precedente e poter reiniziare, giusto?
    Grazie mille

    • Ciao Giacomo,
      hai perfettamente centrato il flusso corretto di lavoro. Ovviamente nulla ti nega la possibilità di pubblicare sul cloud, anche direttamente un branch. Io solitamente, prima di effuare un merge pubblico sempre il branch su github o bitbucket, in modo tale da tener traccia di quanto fatto durante lo sviluppo (soprattuto se il progetto è condiviso).

      Buon lavoro!

  • Giacomo

    Grazie mille per la rapidissima risposta.
    Non ho capito esattamente cosa intendi per pubblicare direttamente sul cloud un branch.

    • per cloud intendo un qualsiasi servizio basato su GIT come github o bitbucket.

  • Maurizio

    Ottima guida, consiglio anche la lettura di questo articolo:
    http://melodycode.com/code/guida-git-per-novizi.html

    usa un approccio learn-by-example con l’utilizzo anche di screenshot (niente di così complicato e approfondito, ma può fare un’idea rapida di cosa è Git).

  • Pingback: Mario Concina - Sindacato Networkers UILTuCS()