Git best practices

of 67 /67
GIT BEST PRACTICES *** MATTEO GAVAGNIN @MACTEO

Embed Size (px)

Transcript of Git best practices

  • 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

    [email protected]

    @macteo

  • GRAZIE