Come programmare con Git e GitHub (Prima Parte)
da Massimo Della Rovere · pubblicato il 18 Maggio, 2017 · modificato il 19 Maggio, 2017

Git è un software dedicato alla gestione e al controllo di versione e contiene molte funzioni utili sia per chi sviluppa solo che in team. Questo strumento fu creato da Linus Torvald nel 2005 per risolvere molti problemi legati lo sviluppo di Linux e alla grande comunità di sviluppatori che fanno parte di questo stupendo progetto. Se volete sapere qualcosa di più sulla storia della nascita di Git vi consiglio di googleare.

Introduzione

In internet ci sono tantissime guide su questo strumento e devo dire che anche la documentazione ufficiale è fatta molto bene. Quindi la domanda sorge spontanea. Perché questa guida? Il principale motivo per cui ho deciso di scrivere questo articolo è che negli incontri di lavoro vedo ancora oggi tantissimi sviluppatori che non usano questo strumento, al massimo usano GitHub per pubblicare parti di codice ma non lo usano come strategia di sviluppo per quello che sono le operazioni di tutti i giorni.

Quindi l’idea è quella di scrivere un articolo dedicato a chi non conosce proprio lo strumento e nello stesso tempo cercare di portare l’attenzione non tanto sui comandi da usare ma sul perché Git potrebbe aiutarci nella programmazione. Oltretutto per chi inizia (come è successo a suo tempo a me) molta documentazione che si trova nel web non chiarisce subito tutti i concetti di base e ti lascia con molti dubbi che molte volte possono bloccare la messa in produzione di questa esperienza.

Metodo classico (svantaggi)

Normalmente in una configurazione classica di un’ambiente di sviluppo abbiamo una directory che contiene in una sotto-struttura ad albero tutti i file sorgenti e le risorse legate alla nostra applicazione. Questo sia se usiamo un solo editor di testo (come io che faccio parte dei vecchietti) sia che si usino sistemi visuali più moderni. Questo approccio ha alcuni difetti nello sviluppo solitario e grandi carenze nello sviluppo in team. Vediamone alcuni anche se sono sicuro che c’è ne saranno molti di più.

Versioni: Ogni volta che si deve creare una versione nuova dell’applicazione bisogna copiare tutti i file sorgenti e le risorse necessarie in un’altra directory e mantenere questa gestione manualmente. In molti casi la gestione della versione non viene neanche gestita e si utilizza sempre la stessa directory per i successivi rilasci.

Roll Back: Se si eseguono delle modifiche ai sorgenti e queste risultassero non idonee al funzionamento della nostra applicazione, per tornare indietro bisognerebbe usare un copia precedente (backup) o ancora peggio andare a rimuovere a mano tutto il codice non desiderato per ritornare alla situazione iniziale.

Conflitti: Se si lavora su più modifiche contemporanee magari fatte da due persone diverse, la gestione di allocazione e modifica dei file può essere molto problematica, non dico che non si possa fare, anzi mi è capitato diverse volte di farlo, infatti se una persona lavora sulla stampa di una fattura e l’altra sull’anagrafica fornitori con molta probabilità andrà tutto bene, ma è ovvio che se la situazione si fa più complessa e le persone del progetto sono diverse allora le cose diventano alquanto ingestibili.

Merge: Se volessi eseguire una modifica complessa alla mia applicazione che dura parecchio tempo e se nello stesso periodo dovessi eseguire anche delle piccole modifiche da rilasciare subito andrei in difficoltà. Infatti anche se usassi due copie dello stesso software avrei sempre il problema di unirle in un’unica versione.

Cronologia: Quando sviluppiamo in un’ambiente statico sia soli che in gruppo non possiamo tenere traccia delle modifiche apportate e tanto meno individuare la persona che ha eseguito una modifica specifica. In ogni caso ottenere un errore generato da modifiche multiple su diversi file sorgenti potrebbe essere problematico da risolvere senza avere una visione delle modifiche apportate e delle linee di codice coinvolte.

Per risolvere tutti questi aspetti abbiamo proprio bisogno di uno strumento come Git, quindi se anche voi vi siete trovati diverse volte in queste situazioni e volete imparare uno strumento che vi possa tornare utile continuate pure questa guida.

Installazione di Git

Per capire il funzionamento di Git direi che la cosa migliore è quella di incominciare ad usarlo insieme con qualche esempio concreto. Quindi per prima cosa procediamo ad installarlo sulla nostra macchina. Il software è disponibile per Windows, Mac e Linux e la sua versione di base è a linea di comando, anche se esistono diversi editor che lo hanno integrato direttamente nella loro interfaccia grafica.

Downloadhttps://git-scm.com/downloads

Negli esempi di questo articolo userò una postazione Linux ma in verità non dovrebbe cambiare molto per gli altri sistemi sia come comandi che come output generato. Se avete installato il software seguendo il link indicato precedentemente eseguiamo il comando per verificare la corretta installazione e la versione caricata:

git version

Se il comando genera un output in cui viene indicata una versione del software allora abbiamo installato correttamente il tutto, in caso contrario leggere la documentazione ufficiale del link precedente e controllare i requisiti del sistema operativo utilizzato.

Il primo repository

Iniziamo con un progetto molto semplice composto solo da tre file. Il primo file può essere un setup generale, il secondo la definizione di una classe e il terzo l’avvio della nostra applicazione. Non è importante il linguaggio che andremmo ad utilizzare, anzi utilizzeremo una codifica di solo logica, quello che conta è seguire la cronologia delle modifiche che andiamo ad eseguire sui file sorgenti del nostro repository.

mkdir /home/user/developer/progetto  // Creazione di una directory
   cd /home/user/developer/progetto  // Spostamento in directory 
touch setup.php class.php init.php   // Creazione di 3 file vuoti

Usiamo il nostro editor preferito e inseriamo nei nostri tre file il codice necessario a dare una logica (per quanto possibile) alla nostra applicazione.

Contenuto di setup.php

define('DATABASE','produzione');
define('TABLE','anagrafica_clienti');

Contenuto di class.php

// Classe principale della nostra applicazione
// Connessione al database tramite constanti

class Applicazione
{
    function connect() 
    { 
        return mysql_connect(DATABASE,TABLE);
    }
}

Contenuto di init.php

$applicazione = new Applicazione();
$applicazione->connect();

Adesso abbiamo la nostra applicazione (non molto complessa a dire la verità :D) che è composta da una directory e tre file sorgenti. Come facciamo a crare un repository Git e iniziare ad utilizzare il software per la gestione delle versioni? Semplicissimo, basta un solo comando di inizializzazione che creerà nel progetto una directory .git.

git init | ls -al

*** OUTPUT ***
drwxrwxr-x 3 massimo massimo 4096 may 18 03:12 .
drwxrwxr-x 7 massimo massimo 4096 may 18 02:47 ..
-rw-rw-r-- 1 massimo massimo  199 may 18 03:12 class.php
drwxrwxr-x 7 massimo massimo 4096 may 18 03:12 .git
-rw-rw-r-- 1 massimo massimo   62 may 18 03:12 init.php
-rw-rw-r-- 1 massimo massimo   71 may 18 03:11 setup.php

Nella directory (.git) verranno creati una serie di file che in questo momento non ci interessa sapere i dettagli del loro funzionamento, casomai affronteremo la questione in un articolo successivo. Quello che importa è che la nostra directory adesso è diventata un repository che possiamo controllare con i comandi di Git.

Decidere i file da tenere sotto traccia

Anche se inizialmente può sembrare strano, il fatto che abbiamo assegnato la directory ad un repository non significa che tutti i file al suo interno vengano tracciati, quindi bisogna procedere indicando a Git i file che vogliamo tenere sotto traccia. Nel nostro caso i file sono tre e possiamo indicarli uno alla volta o usare un wildchar.

git add *.php

Adesso il sistema Git ha tre nuovi file nel suo repository e nessuna versione iniziale che riguarda la nostra applicazione. Per fare questo dobbiamo eseguire un commit, quindi memorizziamo che ogni volta che facciamo un commit è come se facessimo una fotografia alla situazione attuale e congeliamo un punto di ripristino ben preciso. Se non vi è chiaro non vi preoccupate, procediamo e vedrete che sarà tutto più chiaro.

git commit -m "Versione di inizializzazione"

Con l’opzione (m) viene indicato il motivo e le caratteristiche delle modifiche eseguite, questo parametro non solo è obbligatorio ma è molto importante, non lo sottovalutate e scrivete sempre in modo chiaro le caratteristiche dell’aggiornamento.

Riepilogo del nostro primo repository

Ricapitolando abbiamo creato una directory, abbiamo definito tre file che compongono la nostra applicazione, abbiamo inizializzato il repository Git, abbiamo messo i file sotto traccia e alla fine abbiamo creato la nostra prima “versione” con il commit. Cosa succede se andiamo a modificare qualche file? Qui viene il bello di questo strumento, quindi seguitemi nei prossimi passi e mi raccomando eseguite anche voi i comandi.

Controllo dello stato attuale

Prima di procedere con la modifica dei file dobbiamo conoscere il comando “status” che serve ad indicare lo stato attuale del nostro repository, ad esempio se ci sono dei file nuovi da aggiungere, dei file modificati o nessun file presente per il commit.

git status

Se non ci sono modifiche dovreste ricevere il messaggio “nothing to commit”, se invece ci sono dei file nuovi o modificati vedrete un’elenco di nomi di file di colore rosso o verde in base alla situazione collegata al loro stato basato dal comando “add”.

Modificare la nostra applicazione

Procediamo con la modifica di un file sorgente della nostra applicazione, ad esempio potremmo modificare il file init.php nel seguente modo aggiungendo un controllo sulla connessione al database in modo da emettere un messaggio informativo.

$applicazione = new Applicazione();

if ( $applicazione->connect() ) {
    echo "Connessione eseguita con successo".
}

Adesso se eseguite il comando di stato dovreste ottenere quanto segue:

git status

*** OUTPUT ***

En la rama master
Cambios no preparados para el commit:
 (use «git add <archivo>...» para actualizar lo que se confirmará)
 (use «git checkout -- <archivo>...» para descartar cambios)

modificado: init.php

no hay cambios agregados al commit (use «git add» o «git commit -a»)

Scusate per l’output in spagnolo ma ho il PC impostato con questa lingua al momento, in ogni caso possiamo osservare alcune cose: Quando lavoriamo dobbiamo sempre selezionare un (Branch) nel nostro caso è (master) quello assegnato per default, sui tre file che compongono il progetto viene indicato solo quello modificato (in rosso), che però non è ancora idoneo per andare sulla prossima versione, fino a quando non eseguiremo il comando di “add”, a quel punto il file diventa di colore verde e può essere usato per il prossimo commit e quindi per il congelamento di una nuova versione.

git add init.php
git status
git commit -m "Seconda versione con init.php modificato"

Gestione dei commit

Se tutto è andato bene in questo momento dovremmo avere due versioni della nostra applicazione che coincidono con i due commit eseguiti, uno in fase di creazione del progetto con i file originali e l’altro con le modifiche apportate. Come facciamo per controllare questa situazione? Dobbiamo utilizzare il comando log in questo modo:

git log --oneline

*** OUTPUT ***
0902191 Seconda versione con init.php modificato
b475c41 Versione di inizializzazione

Come potete vedere abbiamo in elenco due commit e ognuno di questi è identificato da un codice hash univoco che lo identifica. A essere più precisi vengono visualizzati solo i primi sette caratteri del vero codice hash, che bastano per avere un codice unico da usare nei prossimi comandi, in ogni caso se eseguite il comando git log senza l’opzione di (oneline) dovreste vedere il codice hash completo più altre informazioni.

Ripristino della situazione iniziale

Vediamo qualche beneficio della gestione delle versioni, ad esempio facciamo che la modifica inserita nel file init.php non funzioni bene e che forse quel controllo non sia necessario, come faccio a tornare alla situazione precedente? Basta utilizzare il comando (chekcout) seguito dal numero del commit a cui vogliamo tornare.

git checkout b475c41

Se tutto ha funzionato bene, nel file (init.php) non dovrebbe essere più presente il controllo che avevamo aggiunto dopo la prima versione ma il suo contenuto deve essere tornato alla sua versione originale. Come vedete non c’è più la necessita di gestire diverse copie del progetto in directory separate, con una unica directory gestiamo diverse versioni e possiamo passare da una all’altra con un comando Git.

Conclusione

Dato che non voglio rischiare di fare un articolo troppo lungo che poi vi stancate di leggere, mi fermerei qui e procederei la prossima settimana con un nuovo articolo in cui andiamo ad affrontare la gestione dei Branch e la funzione di Merge. Se volete aggiungere qualcosa o darmi qualche consiglio scrivete pure nei commenti. Nel prossimo articolo andremo a vedere anche perché usare Git con GitHub.

Articoli correlati

5 Commenti

  1. ma e' usabile anche come una specie di "time capsule" in un sito come wordpress ? Intendo dire, faccio una foto dello stato attuale dell'intera directory di wordpress prima di installare un plugin, successivamente installo il plugin ma qualcosa non va e decido di ripristinare il tutto allo stato precedente e ripristino con git la 'foto' precedente. Fattibile ?

  2. No, non penso che puoi fare una cosa del genere. Con Git tu controlli i sorgenti della tua applicazione no il deploy di software di terzi. Quello che dici lo puoi fare, ma nell'ambito di quello che tu sviluppi. Ad esempio io ho un repository per ogni tema che ho creato. In questo caso se faccio delle modifiche e poi ci ripenso mi basta tornare indietro di un commit e riallineare il server. Ma solo per il mio tema no per gli altri componenti.

  3. Adesso alcune cose mi sembrano molto più chiare. Aspetto con ansia il secondo articolo perchè mi è venuta la curiosità di capire anche le funzioni più avanzate. Non ho mai usato GitHub ma dopo questo articolo prometto che il prossimo progetto lo apro con un repository. Ci vediamo al prossimo post. Quando?

  4. Ciao Gustavo, avevo l'articolo già pronto nelle bozze, ho voluto controllare alcune cose prima di pubblicarlo, come vedi non hai dovuto aspettare molto. Grazie, ci vediamo al prossimo articolo.

    Come programmare con Git e GitHub (Seconda Parte)

  5. Ho sempre pensato a Git come un software per sviluppare insieme ad altre persone e l'unica forma con cui lo conoscevo era tramite il famoso sito di GitHub. Leggendo questo articolo ho capito che in veritá posso usarlo anche per lo sviluppo di programmi personali e non ho bisogno di usare per forza dei repository remoti.

condividi