Git best practices
-
Upload
matteo-gavagnin -
Category
Software
-
view
224 -
download
0
Transcript of Git best practices
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 puòessere remoto o locale, ma ogni utente ha almeno la propriarepository locale equivalente alla cartella contenente i file del
progetto.
MASTERBranch principale (e generalmente la prima creata), ma non
necessariamente quella davvero importante.
REMOTECopia remota della repository, ove più utenti possono pushare
le proprie modifiche ed ottenere quelle altrui.
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
TAGEtichetta 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
CONFLICTConflitto.
Può avvenire quando viene fatto il merge tra due branch equeste contengono modifiche alle stesse righe di codice sullo
stesso file.
STASHSalvataggio delle modifiche locali ai file, prima di fare un
commit. Generalemente per poter cambiare branch duranteun work in progress.
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.
SOURCETREESoftware gratuito e multipiattaforma per la gestione
completa delle repository git.
http://www.sourcetreeapp.com
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.
DESCRIZIONI
SIGNIFICATIVESe 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.
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 comerisolto.
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
CONSIGLIOGitHub per i progetti che coinvolgono terzi, open source e con
deploy automatico (capistrano, chef, puppet, ecc).
GitLab per progetti interni su macchina locale.
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.