Versionare il Codice Sorgente usando Git e Github Sistemi di versioning Versionare il Codice Sorgente usando Git e Github

Perchè Versionare il Codice? Per tornare indietro a una versione precedentemente funzionante Per collaborare in un team di sviluppo

Come funziona Git? Gestisce i commit, che rappresentano le diverse versioni di un file o diversi file Un commit salva una versione di un file o di un gruppo di file e presenta l’identificativo del commit (creato automaticamente da git), la data e l’ora dell’operazione, l’autore del commit, il commento che di solito rappresenta le modifiche effettuate o l’aggiunta effettuata in modo da spiegare il cambiamento nel file (creato dall’utente)

Installare Git Se non è già installato di default nella vostra distribuzione, potete installare git usando il comando sudo apt install git

Configuriamo Git Per effettuare i commit è necessario configurare le informazioni dell’utente che verranno riportate nel commit stesso. Configuriamo nome e email dell’utente git config --global user.name "Nome" git config --global user.email "prova@prova.it" Configuriamo l’editor predefinito per la scrittura del messaggio del commit. Per esempio in questo esempio, configuriamo l’editor nano. git config --global core.editor nano

Ogni quanto effettuare un commit Fare un commit per ogni cambiamento logico (per esempio l’aggiunta di una nuova funzionalità, la correzione di un bug)

Che cos’è un Repository È una collezione di file e cartelle di cui è gestito il versionamento tramite una sottocartella nascosta .git Si possono avere più repository sul proprio computer

Come si crea un repository Mettiamo di avere in una cartella sito tutti i nostri file del nostro sito web Index.html Style.css Script.js Cd sito git init (questo è il comando che inizializza un repository Git, praticamente diciamo a Git questa cartella e le sue eventuali sottocartelle dovranno essere monitorate da git) In questa fase se eseguiamo il comando git status Otteniamo un output di questo tipo Sul branch master No commits yet untracked files: (use "git add <file>..." to include in what will be committed) E qui vengono elencati i file e le sottocartelle presente nella directory del sito che possiamo tracciare con Git

Staging area Una volta inizializzato il repository è necessario indicare i file che devono essere “storicizzati”. Questi vanno a far parte della staging area Per aggiungere un file usiamo il comando git add index.html All’inizio, dopo la creazione di un nuovo repository possiamo in pratica aggiungere tutti i file, successivamente, potremo aggiungere solo quelli che hanno subito modifiche rispetto all’ultimo commit. Se vogliamo annullare l’aggiunta del file alla staging area dobbiamo usare il comando git reset index.html Dopo aver aggiunto il file salviamo un’istantanea di questo file usando il comando git commit index.html -m “Creazione del file index.html”

Tornare indietro a un commit precedente Abbiamo fatto delle modifiche a un file dopo l’ultimo commit, ma vogliamo tornare indietro Come facciamo? git reset –hard In questo modo torniamo allo stato dei file della cartella nell’ultimo commit. Attenzione! Perdiamo tutte le modifiche effettuate, ma questo è il nostro obiettivo

Vedere lo storico dei commit effettuati in un branch git log Se non abbiamo fatto alcun commit ci restituisce questo messaggio fatal: your current branch 'master' does not have any commits yet Altrimenti ci restituisce una lista di commit, con gli id, la data e l’ora dell’operazione, l’utente che ha effettuato l’operazione e il messaggio del commit. Per avere una lista con gli id più piccoli git log --oneline

Vedere le modifiche effettuati rispetto all’ultimo commit git diff rileva le modifiche tra la staging area e la working directory (in altre parole segnala se ci sono file modificati che non ancora stati aggiunti alla staging area usando git add) git diff --staged rileva le modifiche tra la staging area e il repository (le modifiche aggiunte alla staging area ma non ancora commitate) git diff commit commit2 differenze tra due commit

I branch Di default alla creazione di un repository viene creato un branch master. Un branch ci serve per attribuire un’etichetta a un insieme di file. Potremmo avere per esempio il branch con la versione rilasciata stabile del nostro software e tanti branch con le diverse versioni in sviluppo. Pertanto è necessario vedere come si crea un nuovo branch Vedremo anche come unire poi i due branch in modo da far confluire le modifiche create nella versione in sviluppo rispetto a quella rilasciata per poi eliminare il branch di sviluppo a operazione terminata. (operazione di merge)

Creare un un nuovo branch git branch nuovo In questo modo viene creato un nuovo branch Attenzione! Con questo comando ci troviamo ancora in master, per spostarci effettivamente nel branch nuovo Occorre digitare il seguente comando git checkout nuovo Adesso possiamo effettuare modifiche, aggiungere file alla staging area, committare senza intaccare il branch master

Effettuare il merge Quando la nostra funzionalità nel branch di sviluppo è pronta e testata, potremmo volerla inserire anche nel branch master. Questa è un’operazione di merge ed è molto delicata. git merge nuovo master L’operazione va a buon fine se nel branch nuovo è stato creato un nuovo file non presente in master. In tal caso verrà aggiunto al branch master. La stessa cosa va a buon fine se un file presente in tutti i due branch viene modificato solo nel branch nuovo. Viene pertanto copiato direttamente il file modificato in nuovo nel branch master Ma cosa succede se sono state fatte modifiche allo stesso file sia sul branch master che sul branch nuovo? L’operazione di merge restituisce un errore di conflitto e pertanto l’unione dei due file deve essere fatta a mano Dopo aver terminato l’operazione di merge non ci serve più il branch nuovo e pertanto possiamo cancellarlo usando il comando git branch -d nuovo

Git stash Tenere delle modifiche senza aggiungere i file alla staging area e senza effettuare commit. E’ necessario fare ciò se occorre salvare delle modifiche in un nuovo branch prima di fare il checkout del master git stash per salvare Torno nel repository master git checkout master git checkout nuovo git stash pop

Usare Github Github è un sito online dove tutti possono condividere il proprio codice, in modo che tutti possano scaricarlo, forkarlo (ovvero fare una copia del repository per farne delle modifiche). Si può eventualmente aprire segnalazioni di errore relative a un software (issues) Si possono poi fare delle modifiche e chiedere che vengano rilasciate sulla versione ufficiale del software (pull requests) Fino adesso abbiamo fatto modifiche a un repository in locale, in questo caso il repository diventa remoto e quindi cambiano alcune cose

Creare un repository su Github Dopo aver creato il repository vuoto su Github Prendiamo il nostro repository di prova già creato e digitiamo questo comando git remote add origin https://github.com/computerluca/prova2.git In questo modo possiamo usare il comando git push per depositare i file sul repository remoto git push -u origin master In questo modo depositiamo i file del branch master del nostro repository locale sul branch remoto in Github.com Possiamo poi ripetere l’operazione di push per tutti gli altri branch che vogliamo pubblicare git push -u origin nuovo

Modificare un file in Github Si seleziona un file, si clicca sul pulsante Modifica, si effettuano le modifiche e quando si salva viene automaticamente generato un commit. Il problema è che in questo caso se facciamo delle modifiche direttamente in Github poi non si riflettono sul nostro repository locale Per recuperare queste modifiche nel nostro repository locale git pull origin master Viene fast un fast-forward merge se non abbiamo delle modifiche in locale e quindi Git deve semplicemente puntare all’ultimo commit registrato nel repository remoto O si può procedere con git fetch git merge master origin/master Ottenendo lo stesso risultato della pull

Creare un fork di un repository esistente Dobbiamo cliccare sul pulsante Fork di un repository scelto. Dopo aver fatto ciò per effettuare modifiche in locale Usiamo il comando git clone passando in input il codice recuperato cliccando sul pulsante Clone or Download Possiamo pertanto fare modifiche git add . git commit -m “modifiche” git push -u origin master

Aggiornare il fork con le modifiche del repository clonato Il repository originale si potrebbe modificare e pertanto dobbiamo riportarle anche sulla nostra fork git pull (recuperiamo il codice cliccando sul pulsante Clone or Download) master Il sistema effettua automaticamente il merge git push -u origin master Anche in questo caso viene fast un fast-forward merge se non abbiamo delle modifiche in locale e quindi Git deve semplicemente puntare all’ultimo commit registrato nel repository remoto