Breve introduzione a GIT: . Iniziare un nuovo progetto o clonarne uno esistente . primi commit e comandi base . esempi di utilizzo Autore: Valerio Radice tag line: Tutorial GIT ITA italiano

1. INTRODUZIONE A GIT
Marzo 2017, Valerio Radice

2. Valerio Radice
valerio.radice@openstyle.it
WEB DEVELOPER & TEACHER
1
https://github.com/valix85
https://plus.google.com/+ValerioRadice85
https://it.linkedin.com/in/valix85/it

3. ▸ Controllo di versione
▸ Introduzione a GIT
▸ Configurazione e uso
▸ Configurazione remota
▸ Branch e utilizzo
2
INDICE

4. Controllo di versione
Cos'è e come usarlo
1.
3

5. VCS CONTROLLO DI VERSIONE
4
Il controllo di versione è un sistema che registra, nel tempo, i cambiamenti ad un file o
ad una serie di file.
Ogni tipo di file può essere sottoposto al controllo di versione
Il sistema che si occupa di registrare la storia di un file, ripristinare i progetto o un file
ad uno stato precedente è detto “Sistema per il Controllo di Versione” o Version Control
System (VCS)
Esempi ?

6. VCS CONTROLLO DI VERSIONE
5
A chi può servire un VCS?
Che tipi di VCS esistono?
Quanto costano?
Servono computer superpotenti?
Internet si / no , cloud?
Progetti per singoli o progetti condivisi?

7. VCS CONTROLLO DI VERSIONE
6
Sistema di Controllo di Versione Locale (VCS)
Gestiti localmente sulla singola macchina
Sistemi di Controllo di Versione Centralizzati (CVCS)
Gestiti in remoto su un server centralizzato, favorisce la collaborazione
Sistemi di Controllo di Versione Distribuiti (DVCS)
Gestisce in remoto su un server la copia principale ma ogni client ha
tutta la storia del progetto, favorisce la collaborazione alta tolleranza ai guasti

8. VCS CONTROLLO DI VERSIONE
7
GIT = sistema di Controllo di Versione
Distribuiti DVCS

9. Introduzione a GIT
Apprendere come funziona GIT
2.
8

10. GIT GESTIONE DEI FILE
9
Git considera i propri dati come una serie di istantanee (snapshot).
Ogni volta che modifichi un file lo stato del tuo progetto in Git verrà aggiornato.
Git fondamentalmente fa un'immagine di tutti i file in quel momento, salvando un
riferimento allo snapshot.
Per essere efficiente, se alcuni file non sono cambiati, Git non li risalva, ma crea
semplicemente un collegamento al file precedente già salvato.
PRO: velocità nel riassemblare la storia a fronte di un'occupazione di spazio non
ottimizzata
CONTRO: maggiore occupazione di spazio rispetto ad altre soluzioni
N.B.: è distribuito

11. GIT GESTIONE DEI FILE
10

12. GIT GESTIONE DEI FILE
11
Git garantisce la storia dei suoi file per ogni distribuzione del progetto.
Questo meccaniscmo che garantisce facilità nel recupero della storia dai client che
utilizzano il progetto in caso di guasti al server principale.
Ogni file in un progetto git è controllato tramite checksum-> tracciamento basato sul
contenuto del file. Ogni cambiamento effettuato al contenuto del file è soggetto al
cntrollo di Git.
Git usa l'algoritmo SHA-1 a caratteri.
In Git i file possono trovarsi in 3 stati differenti:
- modified
- staged
- committed
I file all'interno di un progeto possono essere
tracked o untracked

13. GIT INSTALLAZIONE
12
Git può essere installato seguendo le istruzioni a questa pagina:
https://git-scm.com/book/it/v1/Per-Iniziare-Installare-Git

14. Configurazione e uso
Come configurare il proprio GIT
3.
13
Titolo presentazione - Nome autore

15. GIT CONFIGURAZIONE
14
Il comando 'git config' che ti permetterà d'impostare e conoscere le variabili di configurazione.
Esse possono essere:
- di sistema se si usa il parametro --system varranno per tutti gli utenti e tutti i repository
- per utente se si usa il parametro --global varranno solo per l'utente in uso e per tutti i suoi repository
- per repository se non si usa alcun parametro, varranno solo per il repository corrente.
Ogni livello vince sul livello precedente, così che i valori di progetto hanno più importanza rispetto a
quelli utente che hanno più importanza rispetto a quelli di sistema.

16. GIT CONFIGURAZIONE
15
$ git config --list -> mostra le tue informazioni
$ git config --global user.name “Mario”-> imposta il nome utente (parametro user.name)
per l'utente corrente che verrà visualizzato come autore delle modifiche
$ git config --global user.email ”mario.rossi@test.me” -> imposta l'email per l'utente
$ git config --global core.editor vim -> imposta l'editor predefinito per i file
$ git config --global merge.tool vimdiff -> imposta il tool per risolvere i conflitti i merge
. . .
$ git help config -> ottieni la guida per il comando config
$ git config --help -> ottieni la guida per il comando config
$ man git-config -> ottieni la guida per il comando config tramite il manuale

17. GIT REPOSITORY
16
Puoi creare un nuovo repository ( progetto in GIT ) in due modi:
- convertire una cartella di progetto esistente in un progetto GIT ( $ git init )
- clonare un progetto esistente ( $ git clone [url] )
Una volta iniziato un progetto potrai tracciare i tuoi file semplicemente aggiungendoli a quelli tracked:
$ git add . -> aggiunge tutti i file nella cartella e sottocartella tra quelli tracciati
$ git add nomeFile.txt -> aggiunge il file nomeFile.txt tra quelli tracciati
$ git clone (git|http|https)://url/[nomeProgetto].git PrjDemo-> Scarica e clona tutto il
progetto git dall'url nella cartella di progetto PrjDemo
Quando esegui git clone vengono scaricate tutte le versioni di ciascun file della cronologia del progetto.
Infatti, se si danneggiasse il disco del tuo server, potresti usare qualsiasi clone di qualsiasi client per
ripristinare il server allo stato in cui era quando è stato clonato.

18. GIT CICLO DI VITA
17
Quando editi dei file, Git li vede come modified, perché sono cambiati rispetto all'ultimo commit.
Metti nell'area di stage i file modificati, poi fai la commit di tutto ciò che è in quest'area, e quindi il
ciclo si ripete.

19. GIT COMMAND
18
$ git status -> ritorna informazioni sui file tracciati/non tracciati, modificati e sulla branch in uso
$ git add es1.txt -> aggiunge il file es1.txt nell'area di stage all'istante di esecuzione del comando
$ git commit -m “Fix table error example” -> committa la staing area e ne fa lo snapshot

20. GIT IGNORE
19
GIT mette a disposizione un file .gitignore che permette di ignorare file e cartelle di cui non vuoi
tener traccia ma che risiedono per loro stessa natura all'interno del progetto. Tali file possono essere
ad esempio i file temporanei del tuo sistema operativo o file generati dalla compilazione del
progetto ( che quindi si potranno nuovamente rigenerare in futuro ) o altro ancora.
Per generare facilmente un file .gitignore ( un semplice file di testo ) visita
https://www.gitignore.io/
Altre informazioni
https://git-scm.com/book/it/v1/Basi-di-Git-Salvare-le-modifiche-sul-repository#Ignorare-File

21. GIT DIFF
20
Per vedere cosa hai modificato, ma non
ancora nello stage, digita git diff senza
altri argomenti, questo comando confronta
cosa c'è nella tua directory di lavoro con
quello che c'è nella tua area di stage.
Se vuoi vedere cosa c'è nello stage e che farà
parte della prossima commit, puoi usare git
diff --cached oppure git diff --
staged.
È importante notare che git diff di per sè
non visualizza tutte le modifiche fatte
dall'ultima commit, ma solo quelle che non
sono ancora in stage. Questo può confondere,
perché se hai messo in stage tutte le tue
modifiche, git diff non mostrereà nulla.
$ git diff
Il risultato mostra le tue modifiche che
ancora non hai messo nello stage.

22. GIT COMMIT
21
$ git commit -m “Commit details” -> committa la staing area e ne fa lo snapshot
ATTENZIONE: è bene ricordare che tutto ciò che non è stato inserito nella staging area, o modificato dopo
essere stato inserito nella staging area non verrà committato!
Ogni volta che fai una commit, stai salvando un'istantanea (snapshot) del tuo progetto che puoi
ripristinare o confrontare in seguito.
$ git commit -a -m “Commit demo” -> aggiunge tutto nell'area di stage e committa la staing area
Sono presenti alcune informazioni come la branch sulla quale ho fatto la commit ( master ), il riassunto dei
file modificati e il codice checksum che identifica questo commit.

23. GIT REMOVE
22
$ git rm nomeFile.ext -> rimuove dal repository git (e dal disco!) il file, non tenendone più traccia
ATTENZIONE: è necessario committare la modifica affinche questa abbia effetto.
Per rinominare correttamente un file in GIT bisognerebbe evitare di farlo dal sistema operativo ma usare il
comando:
$ git mv “nomeFileOriginale.ext” “NuovoNomeFileOriginale.ext”
rinomina il file nel nuovo nome ( i doppi apici sono obbligatori in caso il nome contenga degli spazi )
ATTENZIONE: è necessario committare la modifica affinche questa abbia effetto.
GIT RENAME

24. GIT LOG
23
$ git log -> mostra una serie di informazioni sui commit passati, dalle più recenti a ritroso
Tra le informazioni si trovano:
il checksum che identifica il commit
l'autore del commit ( git config user.name )
la data e l'ora di avvenuto commit
la descrizione inserita al momento del commit
Se avviato con il parametro -p mostra il diff dei file,
se si passa anche un numero N limita agli ultimi N
commit la visualizzazione, con il parametro --
word-diff vengono evidenziate le sole parole
modificate.
I simboli “+” e “-” mostrano ciò che è stato
aggiunto e rimosso.
Approfondimento
https://git-scm.com/book/it/v1/Basi-di-Git-Vedere-la-cronologia-delle-commit

25. GIT UNDO
24
$ git reset HEAD nomeFile.ext -> rimuove dalla staging area un file inserito, non ne resetta
le modifiche
$ git checkout -- nomeFile.ext -> rimuove dalla staging area un file inserito e lo riporta allo
stato dell'ultimo commit, resetta le modifiche!
$ git commit --amend -> ripristina l'ultimo commit dando la possibilità di cambiare il
commento, se presenti in staging area gli stessi file ma aggiornati nuovamente essi verranno
caricati con le ultime modifiche ( non perdo le ultime modifiche fatte, vengono “aggiornati” ).
Concettualmente permette di fondere ciò che ho nello staging con l'ultimo mio commit effettuato,
aggiorno quindi l'ultimo commit con i file di cui mi ero scordato.
$ git rebase -i <num_commit> : è utile per fare il pick '&' squash di tutto un pezzo di ramo e
accorpare le modifiche in un unico nuovo commit (posso lavorare in locale con centinaia di commit
per risolvere un problema e caricare un solo commit al remoto )
MAI FARE UN REBASE DI UNA BRANCH LOCALE CHE SIA GIA' STATA CARICATA SU
ORIGIN (remota e condivisa)

26. Configurazione remota
Configurare un repository remoto
4.
25

27. GIT REMOTE
26
$ git remote -v -> mostra l'elenco dei repository remoti ( -v con url ) associati al progetto in uso
$ git remote add <nomeUrlRemoto> <URL> -> aggiunge un repository remoto che si chiama
nomeUrlRemoto e che punta all'indirizzo URL
$ git remote remove <nomeUrlRemoto> -> rimuove l'indirizzo dichiarato col nome
nomeUrlRemoto dal progetto
$ git remote rename <nomeUrl> <nuovoNomeUrl> -> rinomina il riferimento locale di un
repository remoto
$ git remote show <nomeUrlRemoto> -> mostra informazioni sul repository remoto, sulle attuali
brach derivanti da quel repository e sulla predefinita che verrà utilizzata in fase di push
Il repository con il nome “origin” è il repository predefinito remoto ( si crea automaticamente quando
si clona un progetto ), master è il nome predefinito per quello locale.

28. GIT FETCH PULL PUSH
27
$ git fetch <nomeUrlRemoto> -> recupera tutta la storia dal repository remoto, non li unisce al
mio repository
$ git pull <nomeUrlRemoto> -> recupera tutto il contenuto dal repository remoto e lo unisce al
mio repository
$ git push <nomeUrlRemoto> <branch> -> carica il contenuto del tuo repository ( <branch> )
sulla destinazione remota. Fallirà se la tua versione non sarà l'ultima, in tal caso dovrai scaricare e
unire il contenuto remoto col tuo e poi caricarlo.
Approfondimento: https://git-scm.com/book/it/v1/Basi-di-Git-Lavorare-coi-server-remote

29. GIT EXAMPLE
28

30. GIT TAG
29
GIT permette di contrassegnare con etichette ( semplici o annotate ) punti specifici della cronologia
( es: rilascio di versione )
Il comando git tag con i relativi parametri ( -l, -a, -m, -s, -d ) permette di elencare tutte le
tag presenti, crearla ( firmarla con chiave privata GPG ) e cancellarle.
Etichette semplici = molto simile a una ramificazione, non cambia mai
Etichetta annotata = contiene informazioni sull'utente che l'ha creata, si può firmare ( -s ) per
verificarne l'autenticià ( preferite dalla community )
Per vedere i dettagli di un'etichetta annotata git show <nomeTag> , se invece scrivi git tag
“nome etichetta semplice” crea un'etichetta semplice
Per condividere / caricare in remoto l'etichetta si dovrà fare una commit di essa:
$ git commit origin <nomeEtichetta>
$ git commit origin --tags -> carica tutte le tue tags locali sul repository remoto
Approfondimento: https://git-scm.com/book/it/v1/Basi-di-Git-Lavorare-coi-server-remote#Etichettare

31. Branch
Padroneggiare le branch
5.
30

32. GIT STRUTTURA DI UN COMMIT
31

33. GIT STRUTTURA DI UN COMMIT
32

34. GIT BRANCH ( ramo )
33
In Git un branch ( ramo ) è semplicemente un puntatore ad uno di questi commit.
Il nome del ramo principale in Git è master.
Quando inizi a fare dei commit stai spostando il ramo master facendolo puntare all'ultimo commit
che hai eseguito. Ogni volta che invierai un commit, lui si sposterà in avanti automaticamente.

35. GIT NUOVO BRANCH ( ramo )
34
In Git puoi creare facilmente un nuovo branch con il comando
$ git branch <nomeNuovoBranch> -> si crea un nuovo puntatore al commit attuale, non sposta
il puntatore di HEAD.
Il puntatore HEAD serve a informare GIT su quale branch deve lavorare, per cambiare
il ramo su cui lavorare devi usare il comando:
$ git checkout <nomeBranch>

36. GIT NUOVO BRANCH ( ramo )
35
In Git puoi creare facilmente un nuovo branch con il comando
$ git branch <nomeNuovoBranch> -> si crea un nuovo puntatore al commit attuale, non sposta
il puntatore di HEAD.
Il puntatore HEAD serve a informare GIT su quale branch deve lavorare, per cambiare
il ramo su cui lavorare devi usare il comando:
$ git checkout <nomeBranch>

37. GIT EXAMPLE NUOVO BRANCH
36

38. GIT BRANCH
37
Dopo aver modificato un file in una nuova branch ed aver committato il tutto il progetto seguirà due
filoni: il master ( non aggiornato ) e la nuova branch ( aggiornata )

39. GIT BRANCH
38
Posso tornare alla branch master, con i comando git checkout master, in
qualunque momento e decidere di rimodificare altri file o anche gli
stessi file.
Da questo momento il mio progetto avrà due strade parallele.
Sarà necessario unificare i due percorsi e risolvere
gli eventuali conflitti.

40. GIT BRANCH EXAMPLE
39
Caso d'uso: sto lalvorando a un progetto, creo una nuova branch ( iss53 ) per implementare nuove
funzionalità, nel mentre ricevo una richiesta urgente.
- Torno sulla branch master ( quella in produzione ) ( $ git checkout master )
- creo una nuova branch e la setto in uso ( $ git checkout -b iss53 )
- correggo e risolvo il problema facendo diversi commit ( ora l'HEAD della mia branch issue53 è
superiore a quello della master )
- Devo ritornare sulla master per risolvere l'urgenza, committo la mia issue (pulisco così lo staging
area) e torno alla branch master ( $ git checkout master )
- Creo una nuova branch per la mia urgenza ( $ git checkout -b hotfix ) faccio modifiche e
commit sulla hotix e al termine tornerò sulla master ( $ git checkout master ) e farò un merge
con la con essa( $ git merge hotfix )
- Al termine se non mi dovesse più servire la mia branch di hotfix la posso rimuovere ( $ git
branch -d hotfix )
- Torno al lavoro sulla branch della nuova feature ( $ git checkout iss53 ) e alla fine unirò la
branch.
(segue una serie di immagini)

41. 40
Creo la nuova branch iss53 e inizio a modificarla

42. 41
Torno alla master, creo la branch hotfix e faccio le
modifiche

43. 42
Faccio la merge di master con la hotfix (FF FastForward,
sposta solo il puntatore di master).
Il merge crea automaticamente un commit
Rimuovo la branch hotfix e continuo sulla branch is53

44. 43
Completato il lavoro sulla nuova feature, branch is53, devo fare il merge sulla master.
Questa volta però il puntatore di inizio della iss53 è a un punto precedente dell'attuale master.
Git automaticamente identifica il miglior progenitore comune su cui basare la fusione dei rami.
Invece di muovere il puntatore del ramo in avanti ( come prima FF ), Git crea una nuova istantanea
che risulta da questa fusione e automaticamente crea un nuovo commit che punta ad essa.
Questo si chiama commit di fusione ed è speciale perché ha più di un genitore; elimino alla file la
brach iss53 ( non mi servirà più ).
PRIMA
DOPO

45. GIT BRANCH CONFLITTI
44
A volte può non bastare fare una semplice merge per pareggiare i file. Infatti se lo stesso file viene
modificato nella stessa riga GIT non può auto-dedurre quale sarà la correzione da mantenere, si
solleverà un conflitto di fusione ( merge conflict ).
Si possono vedere i file in conflitto con ( $ git status ), GIT non farà il commit automatico, dovrò
risolvere a mano i conflitti, salvare, aggiungere in staging i file corretti e fare una commit.
Dovrò correggere a mano tenendo
presente che nella parte compresa:
tra <<<<<<< HEAD e ======= si trova il
file della brach principale ( master )
e tra ======= e >>>>>>>>> b2 la parte di
codice relativa alla brach più recente
Scelgo cosa tenere e canncello i
simboli inseriti da GIT; aggiungo il file
in stage e preparo tutto per il commit
Mettere in stage il file è come marcarlo
risolto in Git.

46. GIT WORKFLOW (Rami a lunga durata)
45
Puoi avere molti rami che sono sempre aperti e che puoi usare per differenti fasi del tuo ciclo di
sviluppo; puoi fare fusioni regolarmente e frequentemente da alcune di esse in altre. I rami stabili
saranno alla base della storia dei tuoi commit e i rami di sviluppo saranno al di sopra della storia.
L'idea è che i tuoi rami sono a vari livelli di stabilità; quando raggiungono un maggior livello di
stabilità, sono fusi nel ramo superiore.
È anche il
nostro
metodo di
lavoro

47. GIT WORKFLOW (Rami a breve durata)
46
I rami a tema ( o di breve durata ) vengno spesso usati per integrare i rami a lunga durata su piccole
modifiche al codice (come hotfix o pccole funzionalità), hanno commi molto frequenti; è facile
passare da un ramo a un altro perchè le modifiche sono limitate. I rami sono completamente separati.

48. GIT REBASE
47
Puoi prendere una patch del cambiamento che abbiamo introdotto ( altra branch ) per applicarla in
un altro branch ( solitamente il master ) in modo da fare la differenza ( diff ) passo passo per ogni
commit, inserendo tutto in un file temporaneoper poi committarlo. Solo dopo si potrò spostare
agevolmente ( con un merge FF ) l'attuale puntatore master su di esso master. Master e branch ora
hanno lo stesso puntamento con i file uniti.
Non c'è differenza nel prodotto finale dell'integrazione, ma la rifondazione crea una storia più pulita.
Se esamini il log del ramo su cui è stato fatto il rebase, assomiglia ad una storia lineare: appare come
se tutto il lavoro fosse stato fatto in serie, invece è stato fatto in parallelo.
N.B.: Non fare il rebase dei commit che hai inviato in un repository pubblico.

49. GIT WORKFLOW CENTRALIZZATO
48
Crea un singolo repository e dai a ognuno del tuo gruppo la possibilità di effettuare una push.
Git non lascerà agli utenti la possibilità di sovrascrivere il lavoro di un altro. Se uno sviluppatore clona,
fa dei cambiamenti, e poi prova a fare una push delle proprie modifiche dopo che un altro utente
abbia già inviato le proprie modifiche, il server rifiuterà le modifiche dell'ultimo. Sarà avvisato che sta
cercando di fare la push di una copia non aggiornata e non potrà caricare le proprie modifiche finché
non le unirà con quelle effettuate dagli altri.
È anche il
nostro
metodo di
lavoro
https://git-scm.com/book/it/v1/Git-distribuito-Workflows-distribuiti#Workflow-centralizzato
(developer branch)
shared
repository
(master branch)

50. 49

51. Dubbi o domande?
Il mio contatto diretto: valerio.radice@openstyle.it
50
GRAZIE per l’attenzione!

52. BIBLIOGRAFIA & CREDITS
Special thanks to all the people who made and released these awesome
resources for free:
▸ Git Book - https://git-scm.com/book/it/v1
▸ http://rogerdudler.github.io/git-guide/index.it.html
▸ http://marklodato.github.io/visual-git-guide/index-it.html
▸ http://get-git.readthedocs.io/it/latest/index.html
▸ Microsoft Virtual Academy
▸ http://blog.udacity.com/2015/06/a-beginners-git-github-
tutorial.html
▸ https://msdn.microsoft.com/it-it/communitydocs/vs-
alm/alm/riscrivere-storia-in-git
▸ Tool - https://github.com/Readify/GitViz
51