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.
Una modifica apportata al nostro sorgente (repository) viene salvata attraverso l'operazione di commit. Un commit ha solitamente:
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.
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.
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 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
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.
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.
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.
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.
# se sono sul branch master
git merge [NOME BRANCH]
# se sono sul branch
git merge master
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.
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.
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
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>
Con il comando git pull si prelevano le modifiche dal corrispettivo branch da origin e si esegue il merge in locale.
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.