Luca Ottaviano Everyday Git Usare Git per lo sviluppo embedded Firenze, 24 settembre 2012
Chi sono Luca Ottaviano lottaviano@develer.com @lucaotta Sviluppatore su sistemi embedded presso Develer Qt certified developer Sviluppatore Python
Sistemi di controllo revisione Wikipedia: il controllo versione è la gestione di versioni multiple di un insieme di informazioni Repository Struttura dati che mantiene file, directory Ogni cambiamento tracciato nella storia si chiama revisione (commit) Working copy Copia locale del repository ad una certa revisione
Operazioni principali Checkout Crea una working copy locale di un repository Update Aggiorna la working copy all'ultima versione sul repository Revert Riporta un file nella working copy alla versione del repository
Operazioni principali (2) Commit Salva i cambiamenti nel repository Devono essere atomici, cioè implementare una sola funzionalità Bisect Ricerca binaria del commit errato a partire dall'ultima versione funzionante Tutti i commit devono essere atomici Codice sempre compilabile!
Sistemi di controllo versione popolari CVS Storia rappresentata come delta Granularità al file SVN Storia rappresentata come delta Granularità: directory Checkout parziali Sistemi centralizzati
Git: sistema di controllo versione distribuito Distribuito: ogni client ha l'intera storia del progetto Offline: tutte (o quasi) le operazioni non richiedono collegamento al server Veloce: tutte le operazioni sono fatte in locale (eccetto gli update) Ridondato: non c'è un singolo punto di fallimento Sicuro: non si può modificare la storia senza che qualcuno se ne accorga Bisect nativo
Git: operazioni principali Checkout git pull oppure git checkout Git clone Update Git pull git commit -a + git push Commit Git commit -a Git push L'operazione di revert si fa con git checkout
Il metodo migliore per imparare git Flickr: pasukaru76
Flusso di lavoro (1) Lavora con snapshot della working copy Salva lo stato della working copy e pochi altri metadati I file non modificati sono riferimenti allo snapshot precedente
Flusso di lavoro (2) Si fanno modifiche ai file Si aggiungono i file alla staging area Si effettua un commit Stati di un file Unstaged Staged Committed
Commit Snapshot della working copy ad un certo istante + metadati (autore, messaggio, data) Può avere zero, uno o due commit padri Identificato da un hash di 40 byte (SHA-1)
Checkout Riporta i file della working copy allo stato in cui erano quando è stato fatto il commit Può aggiungere e rimuovere file Non funziona se ci sono modifiche locali ai file Sintassi: $ git checkout f5aa747586ec2 # Ritorna allo stato di testing branch # (fra poco vediamo i branch) $ git checkout testing branch
Branch È un puntatore ad un commit Il branch di default è 'master' Il puntatore si sposta automaticamente in avanti quando si fa un commit
Repository remoti Scaricare un repository remoto: git clone Perchè 'clone'? Questo aggiunge un 'remote', cioè un altro repository git Il remote di default si chiama 'origin' $ git clone git@github.com:develersrl/bertos.git Cloning into bertos... remote: Counting objects: 35251, done. remote: Compressing objects: 100% (7106/7106), done. remote: Total 35251 (delta 27927), reused 35251 (delta 27927) Receiving objects: 100% (35251/35251), 7.89 MiB 1.32 MiB/s, done. Resolving deltas: 100% (27927/27927), done.
Repository remoti (2) I branch remoti sono in sola lettura Per fare modifiche si deve creare un branch locale Di default viene scaricato solo il branch 'master' Altri branch vanno aggiunti a mano $ git branch a * master remotes/origin/master remotes/origin/testing $ git checkout t origin/testing Branch testing set up to track remote branch testing from origin. Switched to a new branch 'testing'
Come aggiornare la copia locale git pull: riceve le modifiche dal repository remoto In realtà fa fetch e merge git push: invia le modifiche al repository remoto Non funziona se il branch remoto è andato avanti
Git senza un server remoto Si può creare un repository locale per lavorare da soli Utile per progetti personali, script etc. # entro nella directory con i sorgenti di un progetto $ cd project $ git init. $ git commit a m Primo commit # Fatto! Adesso ho un repository git funzionante! # Faccio delle modifiche... $ vim bar.c #...e salvo i cambiamenti $ git add bar.c $ git commit m Fix bug
Gestione dei branch # creare un branch $ git branch testing # creare e spostarsi sul branch $ git checkout b testing
Gestione dei branch (2) # modifica di un file $ vim foo.c # commit $ git commit a m Useful stuff # qual è la situazione?
Gestione dei branch (3) $ git checkout master # a cosa punta HEAD?
Gestione dei branch (4) # cosa succede se faccio un commit adesso? $ vim bar.c $ git commit a m Other changes
Merge Unione di due branch, si crea un commit con due padri Ricerca automatica del migliore antenato comune (Eventuale) risoluzione dei conflitti
Come ricevere aggiornamenti (advanced) git fetch origin: scarica i nuovi commit da origin git merge origin/master: integra le modifiche nel nostro branch
Come inviare i commit (advanced) Il comando 'push' aggiorna i branch remoti Non funziona se il branch remoto è andato avanti Bisogna fare 'fetch' e 'merge' prima di riprovarci Non si può distruggere il lavoro di altri git push <repo> <mio_branch> git push <repo> <mio_branch>:<branch_remoto>
Let's Talk office +39 055 3984627 (218) e-mail lottaviano@develer.com web www.develer.com twitter @lucaotta Credits Le immagini sono prese dal libro Pro Git http://git-scm.com/book