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

Oggi andiamo ad affrontare la seconda puntata su come programmare usando gli strumenti di Git & GitHub. Nell’articolo precedente abbiamo creato il nostro primo repository, abbiamo visto come aggiungere la tracciabilità ai file, come seguire il commit e come passare da una versione di commit ad un’altra con il comando (git checkout). Questa volta andremo ad eseguire alcuni comandi più avanzati.

La gestione dei branch

Negli esempi dell’articolo precedente non ci siamo preoccupati di questo aspetto ma abbiamo visto che dopo aver creato un repository e aver eseguito diverse modifiche ai file con i vari comandi di add e commit abbiamo sempre usato un branch di default che viene chiamato master. Dobbiamo pensare ad un branch come una linea di sviluppo su cui vengono eseguiti tutti i nostri commit e generare di conseguenza le varie versioni.

Possono capitare dei casi dove si voglia procedere a sviluppare una parte della nostra applicazione in modo distaccato dallo sviluppo di manutenzioni ordinarie che vengono eseguite quotidianamente. Ovviamente questa fase di sviluppo dovrà avere le sue modifiche, le sue differenti versioni e quindi una sua sequenza di commit. Per fare questo bisogna creare un nuovo branch e quindi una nuova linea di sviluppo.

Esempio pratico di branch

Riprendiamo il nostro repository creato nell’articolo precedente, sperando che non lo abbiate cancellato, in ogni caso vediamo la cosa positiva, rifarlo fa bene alla memoria e a rafforzare quello che si è appreso precedentemente :D Supponiamo di voler aggiungere alla nostra applicazione alcune funzioni che non siamo sicuri se verranno rilasciate in produzione e/o non abbiamo idea di quanto tempo possiamo dedicarci. In questo caso ci conviene aprire un nuovo branch con il seguente comando:

git   branch nuova_idea  // Creazione di un branch
git checkout nuova_idea  // Mi sposto sul nuovo branch

Mi raccomando di notare il comando (checkout) che è l’unico modo per passare a sviluppare da un branch ad un altro. Quindi quando vogliamo sviluppare codice per la nuova idea usiamo il branch (nuova_idea) quando dobbiamo modificare la versione corrente per una qualsiasi modifica dobbiamo ritornare nel branch master.

git checkout master      // Branch di sviluppo principale
git checkout nuova_idea  // Branch di sviluppo aggiuntivo
git status               // Controllare il branch utilizzato

Vi consiglio di eseguire diverse modifiche e/o aggiungere anche nuovi file su entrambi i branch, eseguite diversi commit e poi studiate l’output del comando (git status) nei due branch differenti, in questo modo capirete bene la gestione dei branch. Ogni branch ha la sua cascata di commit e quindi di differenti versioni su cui è possibile swicthare.

// Alcuni comandi di esempio con cui fare qualche prova
// Magari usate un esempio pratico di qualche progetto in corso

git checkout master               // Cambio branch
touch master.php                  // Creazione file
git add master.php                // Aggiungo il file
git commit -m "Commit master"     // Eseguo il commit
git status                        // Controllo lo stato attuale

git checkout nuova_idea           // Cambio branch
touch nuova_idea.php              // Creazione file
git add nuova_idea.php            // Aggiungo il file
git commit -m "Commit nuova_idea" // Eseguo il commit
git status                        // Controllo lo stato attuale

Oltre a controllare lo stato di Git guardate il contenuto della directory interessata dopo ogni cambio branch dovreste vedere comparire e scomparire i file in base al branch selezionato, se cambiate anche i contenuti potete fare esperimenti più precisi.

Cancellazione di un branch

Adesso che ci siamo divertiti a sviluppare su due branch diversi ci siamo accorti che la nuova idea non era poi una idea cosi buona come sembrava. Quindi come facciamo per cancellare tutto il branch e tenere solo il branch master? Possiamo usare il comando che abbiamo usato durante la creazione del branch ma con il flag (-D).

git checkout master       // Assicurarsi di stare fuori dal branch
git branch -D nuova_idea  // Cancellazione del branch

Operazioni di Merge

Come abbiamo detto la nostra idea non era tanto buona e l’abbiamo cancellata, ma cosa avremmo dovuto fare se invece risultava giusta e volevamo integrarla nel ramo di sviluppo principale? In questo caso avremmo dovuto usare il comando (merge), il quale provvede a fondere i due rami in uno solo andando ad analizzare le varie modifiche.

git checkout master       // Mi sposto sul master
git merge nuova_idea      // Eseguo il merge con nuova_idea
git branch -D nuova_idea  // Il merge non cancella il branch

Per provare il comando (merge) vi conviene creare un nuovo branch ed eseguire delle modifiche su file diversi di ogni branch (dico diversi per evitare i conflitti che vedremo a seguire sempre nel presente articolo), ritornate sul branch master ed eseguite il comando di (git merge). Analizzate il contenuto dei file e vedete cosa è successo.

Gestione dei conflitti

Durante l’operazione di merge si posso verificare dei conflitti nel caso in cui siano stati modificati gli stessi file e le stesse righe di codice su branch differenti. Ovviamente Git non può decidere da solo quale modifica deve applicare, quindi bisognerà risolvere il conflitto in maniera manuale analizzando le differenze. Per eseguire questa operazione in modo semplice Git ci mette a disposizione del file il codice completo del conflitto.

$applicazione = new Applicazione();

<<<<<<< HEAD
if ($applicazione->connect()) { return true; }
=======
if ($applicazione->connect()) {
 echo "Connessione OK";
}
>>>>>>> nuova_idea

In questo esempio ho modificato il file (init.php) su due branch e poi ho eseguito il comando di (git merge). Dopo il comando mi viene indicato che ho un conflitto ed eseguendo il comando (git status) posso vedere i file dei conflitti in rosso. A dire la verità questa procedura da linea di comando non la uso quasi mai, la trovo molto scomoda, preferisco di gran lunga la stessa funzione integrata in un editor grafico.

Perché utilizzare GitHub

Durante questo tutorial avrete sicuramente notato che abbiamo sviluppato tutto in un’ambiente locale e che tutte le operazioni sono avvenute nelle directory presenti nel nostro computer. In realtà per lavorare in team o per rendere la nostra applicazione condivisibile con gli altri dobbiamo memorizzare il tutto su un repository presente su un server Git. Ovviamente non è strettamente necessario se lavoriamo da soli, anche se in ogni caso sarebbe una buona cosa per una questione di backup.

Esistono due tipi di repository, quelli pubblici e quelli privati, ad esempio se devo sviluppare un plugin per WordPress e metterlo a disposizione di tutti e magari ricevere l’aiuto da qualcuno che possa aggiungere del codice dovrò sicuramente usare un repository pubblico, in questo caso GitHub è sicuramente il più utilizzato. Mentre se sto sviluppando un’applicazione per un cliente ovviamente andiamo sul privato.

Utilizzare un server Git

Per utilizzare un server Git rispetto alle operazioni che abbiamo eseguito nel nostro tutorial le cose non cambiano di molto. L’unica cosa da aggiungere è che invece di creare un repository con (git init) sul nostro computer conviene crearlo sul server Git come GitHub e poi eseguire un comando di (clone) sul nostro computer. Invece per quando riguarda le operazioni fino al commit, rimane tutto uguale, bisogna solo fare una operazione di (push) se vogliamo spedire il tutto al server centrale.

(creare un account su GitHub)
(creare un nuovo repository pubblico)

# git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

(copiare i file nella directory del repository)

# git add .                        // Aggiunta dei file
# git commit -m "inizializzazione" // Commit iniziale
# git push                         // Spedizione al server

Ovviamente ritorno a ripetere che se l’applicazione è personale usate un repository privato e condividete il codice solo con gli sviluppatori autorizzati. Ci sono diverse realtà che mettono a disposizione questo tipo di servizio, io ad esempio uso Amazon CodeCommit il quale è predisposto anche per automatizzare la fase di deploy.

Conclusione

Spero che questo tutorial vi ritorni utile durante la programmazione e lo sviluppo delle vostre applicazioni. Per qualsiasi domanda e/o consiglio che riguarda questa guida potete usare i commenti presenti in fondo al post o venirmi a trovare nelle community presenti in google+ che riguardano WordPress e Cloud Computing.

Articoli correlati

4 Commenti

  1. Grazie, molto utile, sintetico e chiaro. Sarebbe interessante estendere questo approfondimento a quali possono essere le best practice a livello di processo per gestire un team di sviluppo (o governare una community) che usando GitHub porta avanti un progetto open source

  2. Grazie Francesco per il tuo consiglio, in effetti riportare un'esperienza pratica sarebbe molto interessante, io uso diversi repository privati con altre persone, non sono delle grandi community però l'esperienza di fondo dovrebbe essere la stessa.

  3. presumo ci sia un refuso sul listato del codice: hai usato 2 volte il comando git commit -m "Commit ramo master" mentre nel secondo avresti dovuto mettere: git commit -m "Commit ramo nuova_idea" presumo ovviamente :D

  4. Ciao Stefano, hai ragione è il classico errore di copia e incolla. Ho sistemato l'articolo e ti ringrazio per la segnalazione.

condividi