GITBEST PRACTICES

***MATTEO GAVAGNIN

@MACTEO

PROGRAMMA

BASI

ESEMPI

ONE TO ONE

GLOSSARIOINTENDIAMOCI SUI TERMINI

Sistema di controllo di versione distribuito.

Gratuito ed Open Source.

Inizialmente progettato e sviluppato da Linus Torvalds per il

kernel di Linux.

REPOSITORYSistema di gestione del versionamento del codice. Per git puessere remoto o locale, ma ogni utente ha almeno la propriarepository locale equivalente alla cartella contenente i file del

progetto.

COMMIT

BRANCHRamo contenente diversi commit.

CHECKOUT

CHECKOUTScelgo e mi posiziono su una branch.

git checkout

MASTERBranch principale (e generalmente la prima creata), ma non

necessariamente quella davvero importante.

TREEAlbero contenente varie branch, che a loro volta contengono

svariati commit.

REMOTECopia remota della repository, ove pi utenti possono pushare

le proprie modifiche ed ottenere quelle altrui.

ORIGINTipico nome dell'unica remote nella maggior parte dei

progetti.

CLONEDownload in locale di un progetto da una repository remota.

FETCHDownload locale dell'elenco delle branch da un remote.

PULLDownload 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

PUSHUpload dei propri commit sul remote.

git push

TAGEtichetta assegnabile ad uno specifico commit, generalmente

usato per segnalare i numeri di versione rilasciati.

Linee guida su cosa usare come tag:

SEMANTIC VERSIONINGhttp://semver.org

MERGEUnione delle modifiche fatte su una branch, con quelle di

un'altra.

CONFLICTConflitto.

Pu avvenire quando viene fatto il merge tra due branch equeste contengono modifiche alle stesse righe di codice sullo

stesso file.

PUBLISHPubblicazione di una branch locale su una repository remota.

REVERTEliminazione delle modifiche in modo distruttivo a vari livelli:

- riga - file - pi file

RESETAnnullamento distruttivo di tutte le modifiche locali fino

all'ultimo commit.

git reset --hard

STASHSalvataggio delle modifiche locali ai file, prima di fare un

commit. Generalemente per poter cambiare branch duranteun work in progress.

DIFFComparazione dello stesso file tra due commit o tra un

commit e la versione in lavorazione.

REBASEAttenzione: viene sovrascritta la storia dei commit e ne

vengono fatti di nuovi. Usare con molta cautela.

FORKCopia di una repository, generalmente remota, generalmentefatta per poter guadagnare privilegi di scrittura. Molto utile

per fare pull requests in progetti open source.

SUBMODULESotto progetto git nidificato, con remote differente, utile per

poter gestire dipendenze del progetto principale.

PULL REQUESTProposta di cambiamento, composta da uno o pi commit,

residenti su una fork del progetto principale. Se accettata ilmodo di contribuire a progetti open source su GitHub.

ISSUEProblema, ticket, segnalazione.

GITHUBhttp://github.com

Sito di hosting per repository git.

GITLABhttp://gitlab.com

Software open source per hosting repository git.

SOURCETREESoftware gratuito e multipiattaforma per la gestione

completa delle repository git.

http://www.sourcetreeapp.com

DISTRIBUITO

LOCAL

LOCAL REMOTE

DUE LOCAL ED UN REMOTE

DUE CLIENT E DUE REMOTE

DUE CLIENT SENZA REMOTE

MESH

MUST

1 PROGETTO1 REPOSITORY

COMMITPrima 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.

DESCRIZIONISIGNIFICATIVE

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 neicommit e viceversa.

BRANCHAREOgni nuova funzione ha la sua branch, che nasce e muore nel

tempo dello sviluppo della funzione. Non necessariamente

devo pusharla sulla repository remota.

MERGIARECon attenzione e giusta frequenza.

Faccio checkout della branch su cui voglio finiscano lemodifiche e mi tiro il commit dell'altra branch.

CONFLITTIMine: 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

.GITIGNOREescludere dalla repository file e cartelle: builds, dipendenze,

file generati dall'IDE, assets e

CREDENZIALI

SUBMODULESTutto il codice condiviso tra pi progetti, se in forma di

sorgente, deve avere la propria repository ed essere inclusocome submodulo, a meno che la piattaforma su cui state

sviluppando non preveda altri sistemi di dipendenza (gems,cocoapods, npms, ecc).

AUTENTICAZIONESSH oppure Username e Password con keychain, ma

NON DEVE CHIEDERVI LECREDENZIALI OGNI VOLTA

GITHUBVS

GITLAB

GITHUB+ Standard de facto

+ Completo+ Gratis per Open Source

- Costa

GITLAB+ Gratuito

+ Self Hosted+ Open Source+ Funziona bene

- Bisogna mantenerlo

CONSIGLIOGitHub per i progetti che coinvolgono terzi, open source e con

deploy automatico (capistrano, chef, puppet, ecc).

GitLab per progetti interni su macchina locale.

SOURCETREEGUI per git

CompletoMultipiattaformaGratuito

MAC

WIN

IDELa maggior parte degli IDE include direttamente il supporto a

git, ma solo con le funzioni base. il miglior modo per usare git male.

ESEMPICreazione 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.

PRELIMINARIDownload SourceTree

Inserire credenziali GitHub

SLIDESHAREhttps://www.slideshare.net/secret/deEPMnUgEus2vY

MI TROVATE QUI

matteo.gavagnin@dimension.it

@macteo

GRAZIE