Appunti Git
In questo articolo appunterò una traccia schematica di alcune nozioni apprese durante la lettura dell’ottimo book git
Il flusso di lavoro di Git è basato su tre stati, ai quali sono correlate le tre sezioni di un progetto Git:
- Modified: il file è stato modificato. Qui siamo nella Working Directory dove si trova un singolo checkout di una versione del progetto. Sono file estratti dal database (repository) e messi in locale per poterci lavorare.
- Staged: il file modificato nella versione corrente è stato marcato per essere inserito nello snapshot al commit successivo (git add). Staging area (Area di sosta – locale). Si tratta di un singolo file che contiene le informazioni riguardo il commit successivo.
- Committed: il file è archiviato al sicuro nel database locale (git commit -m “descrizione del commit”). Dopo il commit si può fare il push dei dati sul repository. Qui ci troviamo nella Git Directory. Qui Git salva i metadati e il database del progetto. Questo è quello che viene copiato quando si clona un repository da un altro pc. Questo è il repository del progetto.
Di seguito un riepilogo del flusso di lavoro:
- Modifica di un file in locale
- Stage dei file
- Commit per rendere permanenti le modifiche nel repository
Configurazione di git
Settare la propria identità. Queste informazioni vengono utilizzare per i commit in moda da sapere chi lo ha fatto. Le opzioni vengono salvate nel file ~/.gitconfig
git config --global user.name "John Doe" git config --global user.email johndoe@example.com git config --global core.editor vim (Questo fa si che venga aperto vim ad esempio per la descrizione del commit)
Pre elencare le impostazioni settate usare:
git config --list
Inizializzazione di un progetto Git
Questo paragrafo vale se vuoi utilizzare Git con un progetto esistente. Entra nella cartella principale:
git init
In questo modo verrà creata una cartella .git che conterrà i file necessari per il repository ma ancora nessun file è stato tracciato.
git add *.php (oppure git add --all per aggiungere tutto) git commit -m "descrizione del commit"
La prima riga inserisce i file nell’area di stage, la seconda esegue il commit per mettere al sicuro i file nel database. Git add si usa sia per iniziare a tracciare un nuovo file, sia per aggiungere all’area di stage sia già tracciati ma che sono stati modificati. Si usa anche per eseguire la fusione dei file che entrano in conflitto dopo che sono stati risolti.
Partire da un progetto esistente
git clone git://github.com/schacon/grit.git .
In questo modo verranno scaricati tutti i file dal repository git in locale, ogni versione di ogni file della storia del progetto. Il punto finale indica a git di scaricare i file della directory corrente altrimenti verrebbe creata una sotto cartella con il nome del repository
Flusso di lavoro Git – sorgente: http://git-scm.com/book/it/
Ignorare i file
Se non si vogliono mandare tutti i file nel repository è possibile ignorarli creando un elenco di file e/o cartelle nel file .gitignore:
*.[oa] *~ /public_html/upload/
La prima riga dice a Git di non considerare i gile che finiscono con .o oppure con .a, la seconda riga ignora tutti i file che finiscono con la tilde, la terza ignora tutta la cartella upload. Se è necessario rimuovere dal repository file presenti nei commit successivi leggere questa pagina.
Informazioni di stato
Sono due i comandi fondamentali per avere informazioni circa lo stato di git:
git status
git diff git diff --cached (oppure git diff --staged dalla versione 1.6.1)
Il primo si limita a elencare i file nuovi aggiunti alla directory di lavoro e che non sono ancora stati messi nell’area di staged o i file modificati che devono essere ancora committati. Il secondo comando invece indica differenze dettagliate anche sulle righe modificate. Git diff mostra cosa hai modificato ma non ancora messo nell’area di stage, comparando appunto cosa c’è nell’area di lavoro con quello presente nell’area di stage. Git diff –cache mostra invece la comparazione tra ciò che c’è nell’area di stage e l’ultimo commit eseguito.
Il commit
git commit
Con questo comando verrà lanciato l’editor scelto in fase di configurazione per scrivere la descrizione del commit. In alternativa è possibile fare:
git commit -m "descrizione"
Nel commit finiranno solo i file e le cartelle per i quali è stato fatto git add, ossia che sono nell’area di stage. Con l’opzione -v si inserisce nella descrizione la “differenza” dei cambiamenti (diff). L’opzione -a invece permette di saltare il passaggio di parcheggio nell’area di stage, eseguendo quindi autamaticamente un git add –all.
Storia dei commit
git log
Questo comando mostra la storia di tutti i commit effettuati sul repository, tuoi e degli altri collaboratori, il commit più recente è mostrato in alto. L’opzione -p aggiunge il diff nei log e l’opzione – (es. -2) limita agli ultimi 2 commit.
git --stat
Questo comando mostra l’elenco dei commit ma ci aggiunge la lista dei file modificati compreso di righe modificate aggiunte o rimosse.
git log --since=2.weeks
Questo comando mostra i log delle ultime due settimane.
Annullare le cose
Modificare l’ultimo commit
git commit --amend
Questo comando permette di modificare un commit già fatto. Se lo si esegue subito dopo un commit permette di modificare la descrizione, ma se si esegue dopo aver aggiunto o modificato dei file dall’area di stage, allora questi non finiranno in un nuovo snapshot ma nell’ultimo commit fatto. Esempio:
git commit -m 'initial commit' git add forgotten_file git commit --amend
Il secondo commit riscrive il risultato del primo
Annullare le modifiche a un file
git checkout --
Riporta il file all’ultimo commit
Repository remoti
Sorgente remota
git remote
Questo comando elenca i soprannomi di tutti i nodi specificati. Se sei partito con un clone del repository vedrai “origin” che è il nome standard che Git da al Server che hai clonato. L’opzione -v mostra anche l’ulr. Se si hanno più repository la lista sarà tipo questa:
git remote -v bakkdoor git://github.com/bakkdoor/grit.git cho45 git://github.com/cho45/grit.git defunkt git://github.com/defunkt/grit.git koke git://github.com/koke/grit.git origin git@github.com:mojombo/grit.git
Notare che solo origin è un url ssh e quindi l’unico nel quale si può fare il push. Gli altri sono i repository di collaboratori dai quali possiamo attingere i contributi.
Aggiungere un repository remoto
git remote add [soprannome] [url] git remote add pb git://github.com/paulboone/ticgit.git
pb è il soprannome utilizzabile da linea di comando:
git fetch pb
Prelevare da sorgenti remote
git fetch [nome-remoto]
Questo comando si collega al repository remoto e scarica tutti i file che non si hanno
git pull
Questo comando invece oltre a scaricare i file tenta di fonderli con il codice locale con il quale si sta lavorando.
Branching
Per spostarsi in un altro:
git checkout nome_ramo
Creare un nuovo ramo
git branch nuovo_ramo
E’ anche possibile Creare un ramo ed entrarci direttamente:
git checkout -b ramo
Vedere i rami remoti
git remote show origin
Merge dei rami
git checkout master git merge nuovo_ramo
Per prima cosa ci si sposta nel ramo in cui fogliamo effettuare il merge e poi uniamo le modifiche fatte in “nuovo_ramo” con il ramo master. Durante il merge potrebbero esserci dei conflitti se sono stati modificati gli stessi file con più patch. Citando git-scm.com:
“Qualsiasi cosa che ha un conflitto di fusione e non è stato risolto è elencato come unmerged. Git aggiunge dei marcatori standard di conflitto-risoluzione ai file che hanno conflitti, così puoi aprirli manualmente e risolvere i conflitti. I tuoi file conterranno una sezione che assomiglierà a qualcosa tipo:”
<<<<<<< HEAD:index.html contact : email.support@github.com ======= please contact us at support@github.com <<<<<<< iss53:index.html
La versione HEAD (del ramo principale, perche è qui che ci siamo spostati per fare il merge con il nuovo_ramo) è la versione del ramo master, mentre la parte sotto a ====== è la parte di codice del ramo “nuovo_ramo”
Dopo il merge è possibile rimuovere il ramo unito:
git branch -d nuovo_ramo
Lista dei rami correnti
git branch
Il ramo che inizia con un asterisco, è il ramo in cui ci si trova in questo momento. L’opzione -v mostra l’ultimo commit di ogni ramo. E’ possibile anche vedere quali rami sono stati già fusi nel ramo attuale:
git branch --merged
I risultati che non iniziano con un asterisco possono solitamente essere rimossi in quanto già fusi. Per vedere invece i rami non ancora fusi:
git branch --no-merged
Pushing
git push (remote) (branch)
Dry run
Per vedere cosa verrà caricato con il push:
git diff --stat --cached origin/master
Per vedere la differenza di codice tra i file che saranno caricati e quelli già nel repository
git diff origin/master
Per vedere il full path dei file che saranno modificati
git diff --numstat [remote repo/branch]
Fetch
git checkout -b serverfix origin/serverfix git checkout --track origin/serverfix (Con Git >= 1.6.2)
In questo modo creo un ramo locale che si basa sul ramo remoto creato da qualche collaboratore. Questo viene chiamato Tracking Branch, ossia si tratta di un ramo locale relazionato con un ramo remoto. Se sei su uno di questi rami e fai “git push”, Git sa in automatico a quale server e ramo inviare. Stessa cosa per “git pull”.
Per creare un ramo locale con un nome diverso dal ramo remoto:
git checkout -b sf origin/serverfix
Eliminare rami remoti
git push origin :serverfix
Ripristinare un commit
Vedere queste pagine:
git-reset(1) Manual Page
Come annullare una commit in Git