Per chi sviluppa software ma anche per i makers, GitHub si é conquistato un posto di rilevanza e rappresenta una preziosa risorsa. In questo articolo troverai una breve guida alle principali funzionalità di git e del portale GitHub.
Che cos’é GitHub ?
L’idea di rendere il software sempre piú perfetto, ma anche quella di creare delle porzioni di software “riusabili” per piú scopi, sono i concetti su cui GitHub si fonda.
Non é niente altro che un servizio di Hosting su cui lo sviluppatore, dopo essersi registrato, puó caricare il proprio software, rendendolo aperto a chiunque vorrá contribuire allo sviluppo, oppure a chiunque vorrá utilizzarlo nel proprio software.
Un esempio banale, ma molto calzante potrebbe essere: Voglio creare un software “Macchina”, so giá che avró bisogno di principi funzionanti come Ruota, Motore, Sedile, Cambio ecc. ecc. In questo caso ho due scelte: pianifico di voler creare ad uno ad uno tutti i componenti, per poi dedicarmi allo sviluppo della Macchina, oppure posso cercare software libero che include giá i principi funzionanti di Ruota, Motore ecc ecc. Pensandoci bene, la prima idea potrebbe rivelarsi vincente se, nel proprio progetto, questi concetti assumono caratteristiche uniche, innovative. La seconda scelta, in caso opposto, diventa vincente poiché l’investimento di tempo e di energie, é solo per l’idea principale, la Macchina.
GitHub, appunto, ci viene in aiuto nel risolvere questa ricerca: mi collego su GitHub, cerco il progetto piú adatto alle mie esigenze e che sia scritto con il linguaggio che sto usando, faccio una valutazione sulla base di alcune informazioni e lo integro.
Anche se banale, questo esempio é quello che mi permette di spiegare al meglio la questione Riusabilitá e Gestione Delle Versioni a chiunque chi mi fa domande inerenti al tema.
Approfondimenti
Per incrementare il tuo know-how su Git, ti consiglio questi libri:
- GitHub. Piccolo manuale per lo sviluppo collaborativo di software
- Git. Guida per imparare a gestire, distribuire e versionare codice
Ti sengalo, inoltre, la presenza di alcuni titoli interessanti, disponibili gratuitamente nel piano Kindle Unlimited; per approfondire, segui il link sul banner qui sotto:
Git e GitHub
Git é un programma per la gestione delle versioni, trovate tutto il necessario sul sito ufficiale o sulla pagina di wikipedia. GitHub, invece, é un servizio di hosting e di team collaboration, basato sulle funzionalità di Git. Differenza sostanziale, da tenere in considerazione.
Punti Chiave di GIT
arti in poche parole il concetto di Repository e Branch, illustrandoti i comandi ed il workflow piú usato.
Il Repository
Sulla base dell’esempio di prima, stiamo per costruire un team di sviluppo per il progetto Macchina. Una volta formato il team, abbiamo bisogno di iniziare a condividere il codice sorgente del nostro progetto. Per questo, il primo step, é la creazione di un contenitore dove andare a salvare il nostro codice, nelle versioni master ( ovvero, di produzione), develop ( di sviluppo ) ed altre. Questo contenitore, appunto, si chiama Repository.
Ogni contributore del progetto, quindi, avrá a disposizione in locale e in remoto, una copia del Repository con tutto il codice sorgente e la documentazione create dagli altri contributori.
Il Branch
Una volta creato il Repository, il team avrá bisogno di iniziare lo sviluppo del software. Prima del primissimo rilascio, ovviamente, il software sará nella cosiddetta fase di sviluppo. Non appena terminata la fase di sviluppo, peró, il team avrá necessitá di “salvare” lo stato del software, magari rendendolo disponibile all’uso. Contemporaneamente, in base alla progettazione del software, alcuni contributori dovranno continuare la fase di sviluppo. Per non creare caos e stabilire quale elenco di funzionalitá debba contenere una certa versione del software, Git (e GitHub), implementano il concetto di Branch.
Un branch é una sottoparte del Repository che include il codice di una certa versione, derivato direttamente da un altro branch o dalla fusione (merge) di piú branch differenti.
Il commit, il push e il pull.
Quando i contributori iniziato a scrivere il codice in modo organizzato, lo faranno in locale, ognuno sul loro PC. Per inviare le proprie modifiche al branch ? Sará necessario eseguire un commit. Possiamo definire, quindi, il commit come l’azione con cui si decide di trasferire il cambiamento apportato al codice, rendendolo disponibile a chiunque abbia accesso al Repository.
Con l’azione di commit, in veritá, non si invia nulla al repository remoto, e quindi agli altri contributori, ma si genera solo un pacchetto contenente le modifiche. Per inviare il pacchetto bisogna usare il comando Push, mediante il quale il Repository acquisisce le modifiche da un contributore, rendendole disponibili agli altri.
Ogni contributore, per acquisire nel loro Repository locale le modifiche inviate dagli altri, deve effettuare il comando di Pull, medfiante il quale il Repository locale viene allineato con le modifiche presenti sul remoto. L’operazione di allineamento, in alcuni casi potrebbe richiedere l’elaborazione del “merge” manuale, soprattutto quando si lavora sugli stessi files.
Il workflow piú usato
Il branch iniziale, presente in ogni Repository, é il master. A partire dal master, in genere, si genera il branch di sviluppo “develop“. Detto questo, la regola sull’uso dei branch non é unica, ma una delle soluzioni piú diffuse é quella riportata in questa immagine:
Come analizzare questo grafo ? Semplice, leggilo da destra a sinistra e dall’alto verso il basso. L’asse verticale é il tempo, mentre le linee sono i branch. I punti sulle linee sono i commit.
Il team crea la prima versione del progetto nel branch master, taggandone la versione come v 0.1. A partire da questa versione, si crea il branch develop, su cui alcuni contributori iniziano a lavorare e inviando i commit al repository (punti gialli sulla linea develop). I branch piú a sinistra sono denominati feature-branch, ovvero dei branch che racchiudono una funzionalitá complessa, che va gestita a parte rispetto alla normale fase di sviluppo.
Quando il grafo si sposta da destra a sinistra si sta derivando, ovvero si crea un nuovo branch a partire da uno giá esistente, ad una precisa versione (o hash). Tutto il codice del branch a destra sará quindi incluso in quello di sinistra.
Quando il grafo si sposta da sionista a destra, si sta compiendo un merge, ovvero si stanno fondendo le modifiche effettuate su un branch, a desempio di feature, sul branch di develop. Il branch risultante avrá le modifiche effettuate mediante i commit sul branch stesso, piú i commit effettuati sul branch che si sta fondendo. E’ buona regola cancellare tutti i branch che sono reputati “binati morti” per non avere confusione nel Repository.
I merge, quindi, sono effettuati mano a mano da sinistra verso destra, fino ad arrivare al master. La politica scelta per la gestione dei rilasci, é da definire come meglio si crede. Se avete bisogno di approfondire, scrivetemi pure.
Hello, World!
Se vuoi capire quali sono i concetti alla base di GitHub ( e di git ), puoi proseguire la lettura. Ti illustrerò come:
- creare un nuovo Repository GitHub
- creare un nuovo Branch
- apportare modifiche ed inviarle mediante Commit
- aprire una Pull Request
Prima di proseguire, create il vostro account sul sito github.com
Creare un nuovo Repository
Un repository, in genere, é pensato per ospitare un solo progetto. In genere contiene il codice sorgente organizzato per cartelle e puó contenere anche tutti gli assets (immagini, CSS, ecc) utilizzati nel progetto.
Nella parte destra del sito, troverai l’icona “+”, cliccandoci potrai scegliere “new repository”.
Nella schermata di creazione potrai scegliere:
- Il nome del Repository
- Una descrizione
- Se Renderlo Pubblico o Privato
Molto utile é lo strumento di aggiunta del .gitignore (file che permette di escludere path o files dal repository) e il file di licenza, se giá sai quale usare.
E’buona regola corredare il repository di un file README, che contenga la descrizione del progetto. Procedi alla creazione del Repository, per continuare il tutorial.
Creare un nuovo Branch
Procediamo alla creazione del branch develop per rendere possibile l’adozione del workflow sopra descritto: dal dropdown menu branchs, scrivi il nome del nuovo branch e clicca su “create branch: develop”.
Una volta creato il branch develop, puoi notare che includerá tutto il codice del branch da cui é nato, ovvero master.
Apportiamo le modifiche ed inviamole al Repository
A questo punto il nostro Repository avrá due branch separati, uno chiamato master, l’altro develop. Passando al branch develop mediante il dropdown menu branches, andiamo ad editare il file README, aggiungendoci dei testi.
Ti faccio notare come, in basso all’editor, trovi il form in cui devi inserire, il titolo del commit e una descrizione. Queste informazioni servono da guida agli altri contributori, che potranno identificare la natura del vostro nuovo codice. Nel caso del mio esempio, scriveró: Modificato il file README.
A commit inviato, il branch develop mostrará le tue ultime modifiche.
Ti faccio notare che questo modus operandi é totalmente esemplificativo. A seconda del linguaggio di programmazione che userai, farai uso di una IDE che avrá sicuramente il supporto a GIT, ad esempio Visual Studio Code. Tutto il flusso di modifica, push e pull, sará gestito dalla IDE stessa. Scrivimi se hai bisogno di informazioni a riguardo!
Aprire una Pull Request
Come fa un contributore a far capire che le sue modifiche sono pronte per essere spalmate sul branch master ? Si procede con la Pull Request: dal menu Pull Requests del Repository, clicca sul pulsante New Pull Request. Inizierai una procedura guidata per il merge delle tue modifiche.
Scegli il branch sorgente, ovvero quello che contiene i tuoi ultimi commit dal menu comapre”; io scelgo develop per seguire il filo logico dell’esempio. Lascia master nel menu base ed invia la Pull request cliccando su “create pull request”. Si aprirá una finestra in cui potrai notare tutte le variazioni al codice.
In un caso reale, questo passo é fondamentale per la buona riuscita del Pull. Dovrai rivedere con calma come le tue modifiche vanno ad impattare sul codice del branch di destinazione. Al termine dell’analisi, puoi completare la richiesta cliccando su “create pull request”.
Se le tue modifiche non vanno in conflitto con quelle degli altri contributori, il sistemati mostrerá un alert con cui ti avvisa che puoi effettuare il merge senza la necessitá di dover risolvere conflitti.
Una volta confermato il merge, scegliendo un commento al merge, potrai terminare la procedura e chiuderlo. Da questo momento in poi, il branch master avrá lo stesso codice del branch develop.
Go ahead!
Questo semplice tutorial non ha un valore pratico, ma é solo esemplificativo. Avrai bisogno di usare GitHub sul serio per capirne realmente le caratteristiche e le potenzialitá. Ti invito a scrivermi se hai bisogno di suggerimenti sul tuo progetto.
Molti progetti citati nel nostro blog hanno base su GitHub, ti consiglio di analizzare i loro repository per capire come sono stati strutturati. Ti lascio i link agli articoli in cui ne parliamo:
Firmware Tasmota su Sonoff DIY 1 CH
Impara a configurare il firmware ESPEasy
Ti saró grato se condividerai questo articolo aiutando la comunità a crescere.
Restiamo in contatto!
Per non perderti i nostri articoli, iscriviti alla nostra newsletter!
Ciao, mi chiamo Alessandro Lanni. Sono un professionista nel settore IT, ho iniziato la carriera da sviluppatore nel 2002. Mi appassiona l’elettronica amo condividere il know-how: “Cercare risposte e’ meglio che fare domande”
Una risposta.
Ciao, bellissimo articolo che spiega in modo chiaro la logica ci GitHub.
Io, però ho un problema e non so come risolvere.
Premetto che programmo da autodidatta e che ho grosse lacune.
Qualche mese fa mi hanno spiegato le basi di GitHub, oggi ho ripreso ad usarlo, ma mi sono scordato di compilare il signore ed ho commentato per 2 volte un file che vorrei togliere… come si fa???
Grazie mille