Git

Version
Control
Systems

Gestire il sorgente

• Come il sorgente è cambiato...
• ...nel corso del tempo.
• Chi ha fatto cosa e perché.
• Chi sta lavorando su cosa.

• Time machine
• Albero delle modifiche
• Lavoro in parallelo in team
• Debugging
• "Versionamento" del codice

Repository

Il repository è lo storage del nostro sorgente. Può essere un server o una semplice cartella su disco.

Contiene il codice sorgente e tutte le informazioni del nostro sistema di versionamento.

Commit

Una modifica apportata al nostro sorgente (repository) viene salvata attraverso l'operazione di commit. Un commit ha solitamente:

• una data
• un autore
• una descrizione
• un id univoco
• uno o più parent

Working Copy

Il repository contiene tutte le informazioni e i dati del nostro sorgente, ma per lavorare sul nostro sorgente agevolmente non andiamo a modificare direttamente il database del sistema di versionamento.

Solitamente la cartella dove fisicamente risiedono i file del nostro sorgente, apribili con il nostro editor, è chiamata la working copy. Le modifiche ai file nella working copy vengono salvate nel db con i commit.

Branch

I commit vanno a comporre sequenze chiamate branch, o rami di sviluppo.

Vi sono varie filosofie di utilizzo dei branch, non vi è un solo modo di usarli.

Merge

Diversi sistemi di versionamento si trovano a gestire in modo diverso la fuzione tra branch, ovvero l'azione di far confluire nello stesso ramo di sviluppo le modifiche apportate da diversi altri rami di sviluppo.

git

Git è un vcs distribuito 

• Si clona il repository del sorgente sulla propria macchina
• Ogni repository è autosufficiente e copia integrale del sorgente
• Ogni operazione sul repository (commit, branch, merge, etc...) è fatta in locale sul proprio hard-disk
• Tutte le informazioni di un repository git sono contenute nella cartella .git dentro la cartella del repository

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Per prima cosa occorre configurare git con le nostre informazioni che verranno salvate nei commit.

mkdir test
cd test
git init

# oppure

git init test
cd test

Per creare un repository git occorre lanciare il comando git init, il quale inizializza nella cartella corrente la struttura in .git.

A questo punto siamo pronti per fare il nostro primo commit.

echo "Hello World!" > test.txt

git add test.txt

git commit -m "My first commit!"

Per effettuare un commit git deve sapere quali file deve andare a salvare per costruire il nostro commit.

Il comando git add ci permette di preparare uno snapshot di uno o più file.

Con il comando git commit possiamo effettuare il commit salvando nel database di git i file aggiunti con add e un messaggio.

In qualunque momento è possibile controllare lo stato corrente del repository attraverso il comando git status.

È possibile inoltre vedere la lista di commit effettuati sino ad ora in questo repository con il comando git log.

git status & git log

Come è possibile vedere tramite git log, ogni commit è identificato da un lungo hash univoco.

i comandi git spesso permettono di abbreviare il nome del commit chiamandolo con le prime cifre non ambigue.

commit 3ab7b0b8c41939723b3976cbe4c8ebbff0de8fe5
Author: Daniele Maccioni <gendoikari@develer.com>
Date:   Mon Mar 20 23:32:26 2017 +0100

    My commit message!

Per vedere le modifiche correnti nella nostra working copy (rispetto alla versione corrente nel repository git) è possibile usare il comando git diff.

Il diff mostra tutte le modifiche dei file, ovvero cosa finirebbe nel database se quei file venissero committati.

git diff

# oppure

git diff nome_file

Cosa sta succedendo?

Database

Stiamo salvando le nostre modifiche in un database, contenuto nella cartella .git, organizzate per data, autore, sequenza cronologica, etc...

In qualunque momento possiamo visualizzare queste informazioni ed esplorare il sorgente in un modo molto più evoluto della semplice cartella nella quale è contenuto.

Time Machine

Con il comando git checkout è possibile caricare nella working copy lo stato del repository ad un dato commit.

$ git checkout 0ad7

...

HEAD is now at 0ad797e... [COMMIT MESSAGE]

Per tornare al punto corrente si può usare il comando git checkout master.

Commit
Atomici

Questione di disciplina

Git accetta qualunque tipo di modifica al sorgente, in un qualunque numero di file contemporaneamente, senza problemi.
Tuttavia noi ci imponiamo una ferrea disciplina nel modo di fare i nostri commit.

Il modo in cui salviamo la sequenza di modifiche al sorgente (tramite i commit) è di vitale importanza per l'efficacia del tool.

Una modifica concettualmente definita = un commit

I commit sono gratis

Se non so descriverlo non è un buon commit

NO AL COMMIT "MISC"

Branch

Creare un branch

Con il comando git checkout è possibile creare un nuovo branch di sviluppo tramite l'opzione -b NOME_BRANCH.

$ git checkout -b my_new_feature

Per caricare nella working copy branch diversi basta usare git checkout con il nome del branch. Il master è il branch di partenza.

Merge

# se sono sul branch master
git merge [NOME BRANCH]

# se sono sul branch 
git merge master

Conflitti

A volte un merge non può andare automaticamente a buon fine, magari perché sia sul branch che sul master sono state fatte modifiche agli stessi file. In quel caso git marca i file in conflitto con i caratteri <<<<<<<< e >>>>>>>>.
 Una volta risolto il conflitto si può aggiungere e committare.

Best practice

Se si usano branch, spesso si preferisce prima fare il merge del master sul branch, risolvere nel branch i conflitti, testare il buon funzionamento, e poi fare il merge del branch sul master.

Remote

Repository Remoti

Il caso reale sarà che avremo un repository remoto, collocato su un server da qualche parte, che costituirà il repository centrale del progetto.

Il comando git clone con l'address del repository permette di clonarlo in locale.

Il repository locale terrà traccia della sua origine ricordandosi l'url del clone.

git remote -v 

git remote add

I repository remoti possono essere aggiunti e rimossi dal repository locale.
Non sono altro che puntatori con un'etichetta.

L'etichetta di default per il repository remoto di origine è origin.

Con il comando git remote add è possibile aggiungere a mano url di repository remoti con le loro etichette.

git remote add <name> <url>

git pull

Con il comando git pull si prelevano le modifiche dal corrispettivo branch da origin e si esegue il merge in locale.

git push

Si inviano tutti i commit del branch in locale su origin. Prima di poter fare push è necessario aver fatto prima un pull e aver risolto eventuali conflitti.

github.com