Le best practices da seguire per usare git al meglio in un team di lavoro.

1. GIT
BEST PRACTICES
***
MATTEO GAVAGNIN
@MACTEO

2. PROGRAMMA

3. BASI

4. ESEMPI

5. ONE TO ONE

6. GLOSSARIO
INTENDIAMOCI SUI TERMINI

7. Sistema di controllo di versione distribuito.
Gratuito ed Open Source.
Inizialmente progettato e sviluppato da Linus Torvalds per il
kernel di Linux.

8. REPOSITORY
Sistema di gestione del versionamento del codice. Per git può
essere remoto o locale, ma ogni utente ha almeno la propria
repository locale equivalente alla cartella contenente i file del
progetto.

9. COMMIT

10. BRANCH
Ramo contenente diversi commit.

11. CHECKOUT

12. CHECKOUT
Scelgo e mi posiziono su una branch.
git checkout

13. MASTER
Branch principale (e generalmente la prima creata), ma non
necessariamente quella davvero importante.

14. TREE
Albero contenente varie branch, che a loro volta contengono
svariati commit.

15. REMOTE
Copia remota della repository, ove più utenti possono pushare
le proprie modifiche ed ottenere quelle altrui.

16. ORIGIN
Tipico nome dell'unica remote nella maggior parte dei
progetti.

17. CLONE
Download in locale di un progetto da una repository remota.

18. FETCH
Download locale dell'elenco delle branch da un remote.

19. PULL
Download dei commit presenti sulla repository remota,
tipicamente effettuati da terzi. Prima di iniziare a lavorare, è
indicato fare un pull, per limitare al massimo la possibilità di
conflitti.
git pull

20. PUSH
Upload dei propri commit sul remote.
git push

21. TAG
Etichetta assegnabile ad uno specifico commit, generalmente
usato per segnalare i numeri di versione rilasciati.
Linee guida su cosa usare come tag:
SEMANTIC VERSIONING
http://semver.org

22. MERGE
Unione delle modifiche fatte su una branch, con quelle di
un'altra.

24. CONFLICT
Conflitto.
Può avvenire quando viene fatto il merge tra due branch e
queste contengono modifiche alle stesse righe di codice sullo
stesso file.

25. PUBLISH
Pubblicazione di una branch locale su una repository remota.

26. REVERT
Eliminazione delle modifiche in modo distruttivo a vari livelli:
- riga - file - più file

27. RESET
Annullamento distruttivo di tutte le modifiche locali fino
all'ultimo commit.
git reset --hard

28. STASH
Salvataggio delle modifiche locali ai file, prima di fare un
commit. Generalemente per poter cambiare branch durante
un work in progress.

29. DIFF
Comparazione dello stesso file tra due commit o tra un
commit e la versione in lavorazione.

30. REBASE
Attenzione: viene sovrascritta la storia dei commit e ne
vengono fatti di nuovi. Usare con molta cautela.

31. FORK
Copia di una repository, generalmente remota, generalmente
fatta per poter guadagnare privilegi di scrittura. Molto utile
per fare pull requests in progetti open source.

32. SUBMODULE
Sotto progetto git nidificato, con remote differente, utile per
poter gestire dipendenze del progetto principale.

33. PULL REQUEST
Proposta di cambiamento, composta da uno o più commit,
residenti su una fork del progetto principale. Se accettata è il
modo di contribuire a progetti open source su GitHub.

34. ISSUE
Problema, ticket, segnalazione.

35. GITHUB
http://github.com
Sito di hosting per repository git.

36. GITLAB
http://gitlab.com
Software open source per hosting repository git.

37. SOURCETREE
Software gratuito e multipiattaforma per la gestione
completa delle repository git.
http://www.sourcetreeapp.com

38. DISTRIBUITO

39. LOCAL

40. LOCAL ­ REMOTE

41. DUE LOCAL ED UN REMOTE

42. DUE CLIENT E DUE REMOTE

43. DUE CLIENT SENZA REMOTE

44. MESH

45. MUST

46. 1 PROGETTO
1 REPOSITORY

47. COMMIT
Prima di ogni commit, vedere quali file sono stati modificati e
fare il revert delle modifiche inutili.
I commit sono più puliti ed è possibile evitare grossolani
errori.

48. DESCRIZIONI
SIGNIFICATIVE
Se usate un sistema di ticket, riportate il numero #123, ma
anche un breve testo che sarà ricercabile. Sia GitHub che
GitLab permettono di citare automaticamente issues nei
commit e viceversa.

49. BRANCHARE
Ogni nuova funzione ha la sua branch, che nasce e muore nel
tempo dello sviluppo della funzione. Non necessariamente
devo pusharla sulla repository remota.

50. MERGIARE
Con attenzione e giusta frequenza.
Faccio checkout della branch su cui voglio finiscano le
modifiche e mi tiro il commit dell'altra branch.

51. CONFLITTI
Mine: scelgo la versione della branch su cui sono.
Theirs: scelgo la versione dell'altra branch.
Manuale: tool esterno (editor di testo) e poi marchio come
risolto.
NIENTE PANICO

52. .GITIGNORE
escludere dalla repository file e cartelle: builds, dipendenze,
file generati dall'IDE, assets e
CREDENZIALI

53. SUBMODULES
Tutto il codice condiviso tra più progetti, se in forma di
sorgente, deve avere la propria repository ed essere incluso
come submodulo, a meno che la piattaforma su cui state
sviluppando non preveda altri sistemi di dipendenza (gems,
cocoapods, npms, ecc).

54. AUTENTICAZIONE
SSH oppure Username e Password con keychain, ma
NON DEVE CHIEDERVI LE
CREDENZIALI OGNI VOLTA

55. GITHUB
VS
GITLAB

56. GITHUB
+ Standard de facto
+ Completo
+ Gratis per Open Source
- Costa

57. GITLAB
+ Gratuito
+ Self Hosted
+ Open Source
+ Funziona bene
- Bisogna mantenerlo

58. CONSIGLIO
GitHub per i progetti che coinvolgono terzi, open source e con
deploy automatico (capistrano, chef, puppet, ecc).
GitLab per progetti interni su macchina locale.

59. SOURCETREE
GUI per git
Completo
Multipiattaforma
Gratuito

60. MAC

61. WIN

62. IDE
La maggior parte degli IDE include direttamente il supporto a
git, ma solo con le funzioni base.
È il miglior modo per usare git male.

63. ESEMPI
Creazione repository su GitHub;
Clono il progetto sulla macchina locale;
Faccio un commit iniziale;
Faccio una branch;
Faccio una modifica;
Faccio un commit;
Faccio il merge;
Altra branch;
Genero un conflitto;
Risolvo il conflitto;
Faccio il push.

64. PRELIMINARI
Download SourceTree
Inserire credenziali GitHub

65. SLIDESHARE
https://www.slideshare.net/secret/deEPMnUgEus2vY

66. MI TROVATE QUI
matteo.gavagnin@dimension.it
@macteo

67. GRAZIE