Lavoro in Team con Git per Condividere il Codice

Lavoro in Team, Modifica e Condividi il tuo Codice

Nonostante la recente dichiarazione di nuovo percorso, dove ho confessato l'intenzione di trasformare wpAndMore nell'unico portale italiano rivolto allo sviluppatore WordPress, devo ammettere che ultimamente siamo stati un po' assenti...

Contenuti Extra

Non temere: la mancanza di attività nel sito non è dovuta al fatto che stiamo credendo meno in questo progetto, a dirla tutta ci crediamo ogni giorno di più!

Siamo stati lontani dalla pubblicazione perché stiamo lavorando pesantemente ad un nuovo progetto che non vediamo l’ora di presentarti! Purtroppo al momento non è pronta neanche la beta e non posso parlarti direttamente di questa novità: preferisco costruirci sopra un po’ di suspance 🙂

Oggi però faccio una pausa, perché voglio fornirti qualche interessante strumento per collaborare al meglio con il tuo team!

Ti parlo per esperienza diretta perché, a differenza di quanto successo agli albori del progetto AndMore, oggi non sono più da solo a portare avanti questa attività e nel tempo ho dovuto scoprire ed imparare ad utilizzare strumenti che facilitano il lavoro dello sviluppatore.

Oggi affronteremo un argomento più teorico, all’interno del quale però non mancheranno riferimenti e spunti per mettere in pratica i concetti appena presentati. Ma non fermarti a pensare al da farsi: continua immediatamente a leggere!

Ho sempre saputo che, prima o poi, mi sarei scontrato con la necessità di condividere il mio codice con altre persone: il problema è che zippare la cartella contenente i miei file, aggiungere una versione nel suo nome e spedire il pacchetto via email è una pratica più dannosa che altro!

Cosa succede se qualcuno, tra un invio ed un altro, applica delle modifiche ai file? La prima cosa che dovrai fare è controllare se le due versioni presentano delle modifiche diverse da quelle contenute dall’aggiornamento stesso. E, diciamocelo, oltre che essere un’attività mangia-tempo è anche veramente noiosa! Ti sei mai accorto di quanto tempo viene perso soltanto a distinguere le modifiche presenti tra le due versioni?

Negli anni molti sviluppatori hanno incontrato lo stesso problema e hanno proposto diverse soluzioni: le più famose (al momento) sono SVN e Git.

In questo articolo parleremo nello specifico di soluzioni Git, che hanno dimostrato nel tempo la loro flessibilità, ma questo non significa che Git sia la soluzione a tutti i problemi. Molti altri sviluppatori trattato le differenze tra i due formati e dichiarato il vincitore (non sempre lo stesso!), ma personalmente mi sono avvicinato a Git per due motivi principali:

  • è molto utilizzato ed è possibile trovare moltissima documentazione;
  • grazie al servizio di GitHub è possibile creare moltissimi progetti open source (e partecipare a quelli già esistenti) che richiamano anche un gran numero di contributori.

Come puoi vedere, non ho scelto Git per motivi tecnici (benché questi mi abbiano letteralmente illuminato una volta scoperti): semplicemente è lo strumento più veloce che ho trovato per iniziare a condividere i miei progetti.

Se vuoi utilizzare Git per lo sviluppo dei tuoi progetti, la prima cosa che dovrai fare è creare un server Git all’interno del tuo computer, installando e configurando l’applicazione stessa. Se non hai intenzione di fare una cosa del genere, in questo articolo ti presento due servizi che possono fare al caso tuo.

GitHub il Bacino dei Progetti Open Source

La Home di GitHub

A differenza di quanto si possa pensare, GitHub non è Git. Come ti ho detto prima, Git è un programma che puoi installare all’interno di qualsiasi server e che puoi utilizzare per gestire le modifiche che apporterai al tuo codice.

Quello che GitHub rappresenta è un servizio che permette di aprire un numero illimitato di repository che contengono codice di progetti open source. Oltre a questo, all’interno di GitHub è andata a crearsi una potente flotta di sviluppatori che quotidianamente lavorano al miglioramento di questi progetti.

Se non conosci il termine repository questo non è altro che il nome che viene dato al tuo progetto all’interno di un server Git. Nel tuo computer non dovrai far altro che selezionare una cartella ed il gioco è fatto; una volta eseguiti i comandi necessari, Git sarà in grado di controllare il codice presente in quella cartella ed aggiornarlo soltanto sotto tuo comando.

Non tutti vogliono, o possono, lavorare su progetti open source; magari c’è chi vuol tenere nascosti al pubblico i codici sui quali sta lavorando pur mantenendo le possibilità e potenzialità di Git al servizio dei suoi collaboratori. Per questo motivo il servizio di GitHub offre diversi abbonamenti mensili che ci permettono di aprire dei repository privati; ma c’è un altro servizio del quale ti voglio parlare.

BitBucket tutti i Repo Privati che Desideri

Home di BitBucket

Se con GitHub abbiamo la possibilità di creare tutti i repository che vogliamo con l’unico limite che devono essere open source, con BitBucket non abbiamo lo stesso problema.

Grazie a questo servizio sarai in grado di creare tutti i repository privati che desideri anche se, in questo caso, il limite risiede nel numero di collaboratori che puoi avere nel tuo progetto. Entrambi i servizi sono gratuiti da utilizzare, ed al momento entrambi sono perfetti per le mie necessità, ma a seconda dell’utilizzo che ne dovrai fare dovrai mettere in conto questi costi (o valutare la creazione di un server Git tutto tuo 😉 ).

Non Stiamo a Parlare dei Servizi

In questo breve articolo voglio sì descriverti alcuni dei servizi che stiamo utilizzando, ma quello che mi interessa farti conoscere è come muovere i primi passi all’interno di questo innovativo sistema.

Per prima cosa torniamo a fare un po’ di teoria, Git è un Version Control System ovvero un sistema in grado di controllare le modifiche che vengono applicate ai file tra una versione ed un’altra. Oltre a questo ci offre dei potenti strumenti che sono in grado di evidenziare dove sono le differenze tra i file di versioni diverse.

Questo significa che hai integrato nel sistema uno strumento che ti permetterà di capire più rapidamente quali sono state le modifiche applicate e come comportarti di conseguenza. Anche se le funzionalità di Git vanno ben oltre e ci permettono di fare molte altre cose!

Per prima cosa è necessario capire che Git non lavora soltanto sul server e non è neanche in grado di capire da solo quando determinate modifiche vengono considerate stabili. Cerchiamo di fare un esempio semplice con degli elementi che abbiamo di fronte ogni giorno, diciamo che stiamo sviluppando un tema WordPress con altri due amici.

Nel momento zero tu ed i tuoi collaboratori avrete una base di partenza presente sul server Git dal quale ciascuno di voi ha clonato il repository all’interno delle proprie cartelle locali; diciamo che al momento il tema presenta semplicemente questa struttura:

I Primi File di un Tema WordPress

A questo punto ognuno di voi si mette a lavorare su una pagina specifica; chi lavora sulla single.php, chi su page.php e si va avanti così proseguendo per tutte le altre pagine del tema.

Dopo le prime modifiche probabilmente ci saranno le prime comunicazioni, qualcosa come: “Cosa ne pensi della pagina single.php?” sono sicuramente commenti che girano nelle fasi di sviluppo. Il problema è che soltanto la persona che ha lavorato su questa pagina è in grado di vederla, tutto il resto del team ignora le modifiche e la presenza di questo file.

Questo succede perché, come detto anche prima, Git non è in grado di dire questo file è pronto e di caricarlo successivamente all’interno del nostro repository. Per quanto questo possa sembrare un limite, ci evita il problema di dover sovrascrivere le modifiche fatte da un altro sviluppatore.

Per fare in modo che Git sia al corrente della nostra intenzione di inviare un determinato file all’interno del repository principale bisogna fare fondamentalmente due cose:

  1. perparare la staging area aggiungiendo i file;
  2. inviare la staging area nel repository pubblico per fare in modo che tutti gli altri siano in grado di scaricare le modifiche apportate all’interno del proprio sistema locale.

In questi due semplici punti sono stati rivelati alcuni nuovi termini, cerchiamo di spiegare la loro relazione attraverso un semplice schema:

La Struttura di un Progetto con Git

Immagine che trovi sul sito principale di Git

Seguendo questo schema, la logica di Git dovrebbe essere più chiara. Ovvero suddivide il processo di invio e ricezione delle modifiche separando il tutto in tre differenti aree:

  • working directory – questa è la cartella presente nel tuo sistema locale, quello che salva tutte le modifiche che vengono applicate man mano che modifichi i file con l’editor di testo;
  • staging area – grazie a quest’area possiamo iniziare a salvare al suo interno i file che vogliamo preparare per l’invio sul repository;
  • git directory – questa non è altro che l’area che rappresenta il vero e proprio repository sul server Git all’interno del quale vengono salvati i singoli commit ed i rispettivi messaggi descrittivi.

Adesso dovremmo essere sul punto di chiedere: come faccio a inviare i file sui quali lavoro?

Se hai letto attentamente i concetti presentati nella lista precedente, la risposta naturale è “prima di inviare i file nel repository devo aggiungerli alla staging area“. Ma come si fa?

Entrambi i servizi che ti ho presentato offrono degli strumenti grafici per gestire queste situazioni, in pratica non sono altro che applicazioni grafiche che ci permettono di inviare i comandi ai nostri repository Git. Per quanto li trovi degli strumenti utili, è necessario capire che con git installato nel proprio sistema, possiamo agire direttamente da riga di comando!

In questo articolo presumo che tu abbia già installato Git nel tuo sistema, le procedure sono veramente semplici e molti strumenti vengono offerti direttamente dalla home del progetto. Non esitare a fare i tuoi esperimenti scaricando direttamente l’ultima versione. Se poi hai bisogno di aiuto, non esitare a contattarci!

Per inserire il file appena modificato all’interno della propria staging area, tutto quello che devi fare è entrare con il terminale all’interno della cartella contenente il progetto e aggiungere:

Con questa semplicissima riga di testo hai appena detto a Git di aggiungere il file single.php alla nostra staging area. A questo punto bisogna creare il nostro primo commit.

Se stai ancora riflettendo sul significato di commit, diciamo che è il comando che ti permette di far conoscere a Git che tutte le modifiche che hai fatto fino ad ora sono pronte per essere spedite con un messaggio descrittivo.

In questo contesto, il repository online non conosce ancora queste modifiche, per il momento abbiamo aggiornato il server Git che abbiamo sul nostro sistema locale. Tutto quello che manca per riuscire ad inviare le modifiche effettuate è la presenza del comando push.

Ancora una volta, in questo articolo introduttivo sto dando per scontato alcune conoscenze che dovresti già avere come, ad esempio, il fatto che il Git installato sul tuo computer deve essere già a conoscenza del repository online dove dovrà inviare i file modificati. Se questo ti fa innervosire mi dispiace ma ti assicuro che torneremo a breve a trattare questi aspetti in un prossimo articolo.

Con questo comando non facciamo altro che dire al nostro Git di prendere le modifiche presenti nel repository locale (in questo caso identificato con master) e di spedirlo su quello online (che in questo caso è origin). Queste informazioni ti saranno messe a disposizione dallo stesso Git sia in fase di configurazione che utilizzando il comando git status.

Eseguito questo comando le modifiche presenti nel file single.php saranno rese disponibili a tutti gli altri sviluppatori appartenenti al team di sviluppo, tutto quello che dovranno fare è scaricare i file presenti nel repository online ed il gioco è fatto!

Ti lascio con la curiosità di scoprire il comando necessario per scaricare le modifiche presenti nel repository online perché questa lezione, da introduttiva che voleva essere, è diventata più lunga del previsto. A questo punto non mi resta che chiederti: sei interessato a conoscere Git più nel dettaglio?

Te lo chiedo perché, come anticipato precedentemente, stiamo già lavorando per pubblicare un nuovo articolo dove entreremo più nel dettaglio ma onestamente stiamo pensando anche di creare un corso completo.

Spero che la lettura e l’incontro di questo nuovo strumento possano essere di aiuto al tuo lavoro, se stavi già utilizzando Git perché non condividi con noi le situazioni in cui ti è stato indispensabile? Sono sicuro che sarà veramente utile conoscere le esperienze di altri sviluppatori e sopratutto aiuterà i novizi a capire perché è importante lavorare con un Version Control System 😉

Lascia il tuo Pensiero