Git

packz

Servono kTln2 joules d i energia p er trasmettere un bit d i informazione in un am biente a temp eratura T

GitP ublished on 06/ 03,2007

[ATTENZI ONE : pa gina in via di comple ta mento]

Git è un programma distribuito per i l controllo di "revisione" (maledetti termini inglesi[1][2]) di

progetti software creato da L inus Torvalds per gestire lo sviluppo del kernel ormai giunto ad un numero

di righe di codice probabilmente insostenibile per una persona normale. Il progetto partì i l 3 Aprile 2005

e già nel giugno dello stesso anno i l kernel incominciò ad essere gestito attraverso questo fantastico

strumento. Visto l 'odio viscerale che i l caro nostro amico (?) nutre per i l sistema alternativo chiamato

CVS (vedere video) e altri sistemi analoghi, ha deciso di scriverne uno lui stesso.

Qui di seguito presenterò Git nella maniera in cui l 'ho imparato: non- linearmente, per attività pratiche; i

comandi non direttamente sperimentati avranno un l ink ad una possibile documentazione specif ica.

Caratteristiche

Supporto per lo sviluppo non l ineare attraverso "branching" e "merging" e supporto per la

visualizzazione della loro storia.

Sviluppo distribuito: ognuno ha la propria copia locale sulla quale può fare tutte le modif iche di cui

sente i l bisogno per poi poterle pubblicare ed eventualmente gli amministratori del progetto

potranno fare i l merge da quel repository.

Fac il ità di pubblicazione remota attraverso un protocollo apposito (git:// appunto) anche se

accessibile anche rispetto ai più tradizionali http, f tp, ssh etc ...

Util izzo della crittograf ia per la gestione della storia e dei "commit".

Installazione

Per installarlo su un sistema debian- like ai necessitano dei seguenti pacchetti

git-core

git-doc (se desideri avere la documentazione in f i le:///usr/share/doc/git-doc/index.html)

gitk (se si desidera visualizzare graf icamente gli sviluppi)

git-daemon-run (se si desidera rendere disponibile tramite protocollo git gli sviluppi)

git-completion (se si desidera avere i l completamento dei comandi da l inea di comando)

git-email (per le funzioni legatate al mandare patch via email)

git-gui (interfacc ia spartana per le operazioni di base)

packz | Git http://packz.noblogs.org/post/2007/06/03/git

1 di 17 16/11/2008 22:56

git-buildpackage (permette di importare pacchetti sorgenti come repository di git)

Fare attenzione che la versione nei pacchetti dif ferisce molto da una distribuzione ad un'altra causa

l' incessante attività degli hacker che lavorano sopra Git (sono iscritto al la ml e mi arrivano c irca 50 mail

al giorno quando stanno tranquil l i).

Concetti

Git basa i l suo design sull ' idea che non c 'è uno sviluppatore migliore degli altri: non vi è la necessità

che esista un repository princ ipale a cui tutti debbano riferirsi, ma permette anzi uno sviluppo

distribuito, dove ognuno può, una volta che ha scaricato i l codice, apporre delle modif iche e ripubblicare

a sua volta i l codice permettendo modif iche ulteriori;

Al contrario di altri programmi di questo tipo, lui non elabora f i le, ma i contenuti dei f i le, L inus stesso lo

descrive come content-addressable; contiene due strutture dati

Un indice mutevole che raccoglie le info sulla directory di lavoro corrente e sulla versione

successiva che verrà importata.

1.

Database di oggetti (immutabile).2.

In particolare esistono varie tipologie di oggetti:

Blob: semplicemente un insieme binario di dati che non si riferisce a niente altro. A basso l ivello

viene creato tramite git-update-index , mentre i l contenuto può essere visualizzato tramite

git-cat-file.

Tree: è un oggetto che lega assieme blob e/o tree; viene creato tramite git-write-tree e visualizzato

attraverso git-ls-tree

Commit: introduce i l concetto di "storia": è rappresentato dal tree risultante, dal commit

ef fettuato/i per arrivare a quel punto e dal commento a questi.

Tag:identif ica simbolicamente altri oggetti, tramite l ' identif icazione ed i l tipo dell 'oggetto

Si può riconoscere in questo schema un graf ico c ic l ico diretto.

Ognuno di essi viene denominato attraverso un Hash SHA-1 di 40 c if re esadecimali creato con i l

contenuto proprio dell 'oggetto. Questo codice può essere util izzato per riferirsi a ben determinati punti

(temporali) del progetto.

Capito come funziona a basso l ivello questo astuto programma, potete immaginare che la grandezza più

util izzata è i l tree: siccome un commit punta ad un tree ed una tag punta ad un commit, entrambi

possono essere usati indistamente. In maniera analoga una tag è simil commit quindi può essere usata

quando si richiede un commit.

Specif icando il nome di una referenza, git la cerca in una di queste directory

.git/ (or $GIT_DIR)

.git/refs/ (or $GIT_DIR/refs/)

.git/refs/heads/ (or $GIT_DIR/refs/heads/)

.git/refs/tags/ (or $GIT_DIR/refs/tags/)

Esistono inoltre una grammatica ben prec isa per riferirsi alle referenze: la testa del ramo corrente di

sviluppo viene indicato con HEAD (si trova in .git/HEAD) ed è un riferimento ad un elemento in .git/refs

/heads/; è possibile usare l 'operatore postf isso ^ per indicare i l genitore di una data referenza. Siccome è

possibile usarlo più volte esiste la regola che l 'applicazione ripetuta N volte di ^ può essere sostituita

con l 'operatore postf isso ~ seguito da N: c ioé

HEAD^^^ è equivalente a HEAD~3

Siccome questi riferimenti sono ovviamente legati al la situazione attuale del ramo di sviluppo, è


2 di 17 16/11/2008 22:56

possibile conoscere la referenza assoluta usando

git rev-parse REFERENZA

quindi nel caso precedente basta dare git rev-parse HEAD~3 per sapere a quale commit si riferisce. Una

descrizione più approfondita la si può trovare tramite git rev-parse --help alla sezione SPECIFYING

REVISIONS da cui potrete capire f igure quali

G H I J

\ / \ /

D E F

\ | / \

\ | / |

\|/ |

B C

\ /

\ /

A

A = = A^0

B = A^ = A^1 = A~1

C = A^2 = A^2

D = A^^ = A^1^1 = A~2

E = B^2 = A^^2

F = B^3 = A^^3

G = A^^^ = A^1^1^1 = A~3

H = D^2 = B^^2 = A^^^2 = A~2^2

I = F^ = B^3^ = A^^3^

J = F^2 = B^3^2 = A^^3^2

Getting started

Oltre a voler capire come sono implementate le funzionalità di git, magari vorrete usarlo no? no

problema, per questo esiste questa parte: cerchiamo di esplicare i comandi fondamentali e/o più uti l i ,

anche se, per un approfondimento, rimando alla documentazione uf f ic iale.

Supponiamo che abbiamo appena iniziato un nuovo progetto e che c i troviamo nella directory in cui i l

progetto stesso risiede, per inizializzare i l repository bisogna eseguire[3]

git init-db

e di seguito

git add . se si vuole importare tutto, oppure git add file_1 ... f ile_n se interessano solo c erti file

Visto che lo scopo princ ipale di questo programma è i l tracc iare i cambiamenti, una volta che si è

lavorato su un albero di sorgenti si possono controllare i cambiamenti attraverso

git status


3 di 17 16/11/2008 22:56

che rende noto i f i le modif icati ma non "committati" , i f i le che non vengono inseriti etc ..lo schema di

uti l izzo è i l seguente: via via che si fanno le modif iche e si interessa salvarle nel prossimo commit, si

aggiungono i f i le uti l i tramite git add; per ef fettuare ef fettivamente i l commit

git commit

che indic izza tutti i cambiamenti memorizzati nell ' index (bisogna scrivere i l commento ed è

consigliabile dividerlo in uno riassuntivo ed uno più esplicativo separati da una l inea vuota). Per

ricordarc i quali sono i cambiamenti che sono stati apportati f ra indice, repository e working tree viene in

aiuto i l comando git diff : normalmente questo comando restituisce la dif ferenza f ra i l working tree ed i l

repository senza tenere conto delle modif iche già inserite nell ' indice (in pratica fa un dif f f ra working

tree e indice per farla breve); per avere info a riguardo al codice inserito nell ' indice rispetto a quello del

repo si aggiunge l 'opzione --cached al comando.Altra simpatica opzione che aiuta la visualizzazione è

--color che rende di colore rosso o verde le righe rispettivamente tolte o aggiunte.

È anche possibile conf igurare git in maniera tale che inserisca in automatico i vostri dati nei commit: nel

mio caso nel f i le .git/conf ig ho inserito le righe

[user]

name = "packz"

email = "packz at autistici dot org" [ovviamente tu c he non sei un bot fai i c ambiamenti del c aso]

È evidente che è possibile inserire nuovi f i le in qualunque momento nel progetto usando sempre git add

ed è inoltre importante tenere conto del fatto che è possibile usare wildcard per scegliere f i le che

rientrano in un ben determinato schema: per esempio

git add directory_generica/*.txt

inserirà nell ' indice tutti i f i le che hanno estensione txt (la barra davanti all 'asterisco preserva quel

carattere dall ' interpretazione fatta dalla shell e nel caso di git inserisce f i le txt anche di sottodirectory).

Nel caso abbiate bisogno di eliminare un f i le dall ' indice potete usare

git rm

che appunto, si occupa dell 'operazione inversa di git add (non è proprio così). Nel caso necessitate di un

messaggio standard nei commit, è possibile impostare nella conf igurazione un f i le contenente i l

template di questo messaggio tramite i l suo path relativo alla working dir:

[commit]

template = .git/commit-template

dove ovviamente dopo template potete inserire i l percorso che volete.

Comandi utili

Git dispone di varie funzionalità che richiamano le uti l ity da riga da comando tipiche del mondo *nix e


4 di 17 16/11/2008 22:56

che permettono la gestione e la lettura del codice nel la sua evoluzione temporale e non; uno dei comandi

è git blame che permette di vedere ad ogni l inea di un dato f i le chi lo ha modif icato e quando, potendo

limitare ad un dato range di questo tramite anche espressioni regolari: per esempio

:) $ git blame -L ' /^ f unct ion generate_script _js( /,/^ }$/' private/P hp/rout ine.php

96c53bd8 ( packz 2007-06-09 16:11:57 + 0200 46) f unct ion generate_script _js( $src ) {

96c53bd8 ( packz 2007-06-09 16:11:57 + 0200 47) $js = "< script t ype= "text /javascript " src= "$src" rel= "javascript "> ";

96c53bd8 ( packz 2007-06-09 16:11:57 + 0200 48) $js .= "< /script> n";

96c53bd8 ( packz 2007-06-09 16:11:57 + 0200 49) return $js;

96c53bd8 ( packz 2007-06-09 16:11:57 + 0200 50) }

restituisce le righe delle def inizione di una funzione Php. Inoltre è capace di tracc iare l inee di codice

spostate da un f i le all 'altro passandogli l 'opzione -C (seguendo questo consiglio di Torvalds, è meglio

copiare, fare i l commit e poi modif icare quelle l inee).

Altro comando è git grep che come l'omonimo da shell cerca l 'occorrenza di una determinata stringa

nel f i le passato come argomento (nice l 'opzione --color che permette una lettura più chiara).

È possibile anche conoscere in quali commit un dato f i le è stato cambiato tramite

git whatchanged path/to/file

(senza i l nome del f i le restituisce un log con tutti i f i le modif icati).

Forse la vera potenzialità sta proprio in questa caratteristica che permette di "montare" opportunamente

i singoli comandi per ottenerne di nuovi: supponiamo di voler conoscere i l numero di l inee a cui

ammonta ogni singolo f i le del progetto, usando le funzionalità della shel l bash e i comandi di git questo è

possibile tramite i l comando

for i in $(git ls-files); do wc -l $i; done | awk '//{VAR+=$1; print $0}END{print "totale: "VAR}'

oppure è possibile conoscere i l numero di persone diverse che hanno contribuito al codice presente nel

repository (fonte)

git log --pretty=short | sed -n 's/^Author: $[^<]*$<.*$/\1/p' | sort | uniq | wc -l

Branch&Tag

Esistono due cose fondamentali nello sviluppo del software: la possibil ità di provare nuove soluzioni e la

possibil ità di impostare a determinate conf igurazioni del codice dei nomi/versioni da poter porre come

punti fermi nello sviluppo. Questa possibil ità sono espresse da Git attraverso i branch e le tag.

Per branch si intendono delle " l inee concettuali" di sviluppo in cui suddividere i l progetto, possono

essere derivate da progetti esterni (tracking branches) oppure provenire da cambiamenti minimi dal

ramo princ ipale (topic branches). Al l ' inizio esiste solo i l branch chiamato master ma è semplic issimo

crearne di nuovi e uti l izzarli acrobaticamente passando da uno all 'altro!!!

Un semplice

git branch


5 di 17 16/11/2008 22:56

restituisce l 'elenco dei branch disponibil i , mentre per crearne uno di nome 'hazardous' si abbisogna del

magico comando

git branch hazardous

a cui sarà possibile accedere attraverso

git checkout hazardous

e fare le modif iche senza modif icare i l ramo master; riuti l izzando git branch si otterrà

master

* hazardous

con l 'asterisco ad indicare i l branch in cui si stanno ef fettuando le modif iche. Nel momento in cui c i

ritroviamo con del codice in un branch "experimental" che riteniamo oramai stabile, possiamo unirlo al

branch princ ipale tramite i l merging:

git merge ["qui un commento" master] hazardous

oppure spostarc i nel branch voluto e poi eseguire semplicemente

git merge hazardous

se non c i saranno problemi i due rami saranno uniti in uno solo e quello master conterrà i cambiamenti;

git possiede degli algoritmi per gestire la fusione di codice nello stesso f i le, ma non è detto che i l tutto

sia possibile, in questo caso nel f i le (o nei f i le) interessato/i saranno presenti delle l inee in sti le dif f con

evidenziati i problemi (appena sarò più pratico vi farò sapere). Se non pensate di ef fettuare più

cambiamenti da quel branch lo potete cancellare tramite

git branch -d hazardous

In una sola mossa è possibile anche creare e spostarsi nel nuovo branch tramite

git checkout -b hazardous

inoltre è anche possibile fare i l checkout di una versione più vecchia usando il commit come argomento

per poi aprire un nuovo branch da quel punto usando la regola appena insegnata. È anche possibile creare

dei branch "vuoti" c ioé dei rami di sviluppo senza parents: i l metodo da usare è un po' tricky e ve lo

espongo nel seguito


6 di 17 16/11/2008 22:56

$ git-symbolic-ref HEAD refs/heads/mybranch

$ git rm --cached -r .

$ rm * # questo serve quando si cambierà branch per evitare errori

$ git commit --allow-empty

è utile per creare del codice parallelo al progetto di sviluppo ma che può non interessare i normali

developer, per esempio la web page del progetto etc ...

Si può uti l izzare i l checkout per invertire i cambi local i al proprio archivio locale tramite

git checkout -f

che in pratica riporta all 'attuale ramo il contenuto della directory.

Per quanto riguarda i tag invece è ugualmente semplice la loro gestione:

git tag -l <pattern>

visualizza i tag con un nome che rispecchia i l pattern passato, mentre

git tag <label>

imposta <label> come tag della attuale versione.

Rebasing

È anche possibile che vi troviate in questa situazione

A---B---C topic

/

D---E---F---G master

e vogliate aggiornare il branch topic con master in modo da ottenere la situazione

A'--B'--C' topic

/

D---E---F---G master

senza dover fare un branch temporaneo e spostare le patch per ricreare la situazione: vi viene in aiuto

git rebase! basta in questo caso dare

git rebase master topic


7 di 17 16/11/2008 22:56

che passa al branch topic ed ef fettua appunto i l rebasing; nel caso foste già in topic so potrebbe togliere

l'ultimo argomento.Questo comando è molto potente in quanto permette di modif icare i singoli commit

fondendoli o dividendoli all 'occorrenza per sopperire a qualsiasi necessità. Nel caso c i siano dei problemi

è possibile annullare l 'operazione tramite

git rebase --abort

Esiste anche una versione interattiva di questo comando nelle ultimissime versioni a cui si accede

(sorpresa) con

git rebase --interactive

Errare humanum est

Può capitare di sbagliare ed infatti ecco qualche comando utile per invertire l 'errore

git checkout FILE -

git reset - dimentica nuovi f i le aggiunti

git reset --hard - tralasc ia i cambiamenti

git reset --soft HEAD^ - cancella l 'ultimo commit ma lasc ia i cambiamenti

git checkout -m branch_corretto nel caso si sia iniziato a fare cambiamenti nel branch errato

Bisecare i bug

Succede appunto di sbagliare durante la produzione del codice, ma magari ce ne accorgiamo (molto) in

seguito,magari qualcun'altro che i l risultato del nostro lavoro lo usa in maniera dif ferente e nel

f rattempo sono stati pushati svariati commit nel repository e non possiamo sapere direttamente quale

commit in particolare ha introdotto un baco: a questo viene aiuto i l comando git bisect che si preoccupa

di creare un branch temporaneo e di ef fettuare una operazione di dicotomia sulle parti del codice

Io personalmente non l 'ho provato ancora, ma potete trovare dalle parole del sommo il suo util izzo.

Importare un repository remoto

È importante anche poter importare da una locazione remota un progetto che c i interessa, in maniera da

apportare le modif iche da eventualmente rispedire al mittente (w l 'open source); per mettere in pratica

questo i l comando è

git clone <uri>

che crea nella directory corrente i l contenuto del repository e due branch: master e origin, di cui i l

primo, per convenzione, è preposto alle modif iche. Per aggiornare i l contenuto locale rispetto a quello

remoto è usato i l comando

git pull

(l ' indirizzo da cui proviene è nel f i le .git/remotes/origin).

Di default viene scaricato solo i l ramo master di un repository, per ottenere tutti i rami presenti eseguire

git branch -r


8 di 17 16/11/2008 22:56

che restituirà qualcosa come

origin/HEAD

origin/label_placing

origin/master

origin/menu_on_client

origin/pdf_profile

origin/xform

origin/xslt

a questo punto con un bel

git checkout --track -b local_branch_name origin/remote_branch

creerà un branch locale chiamato local_branch_name a partire dalla referenza origin/remote_branch e lo

sincronizzerà con quello remoto.

Patching

Una ulteriore chicca di questo programma è la possibi l ità di generare delle patch da spedire per posta

tramite i l comando (con l 'opzione -n e più patch speci f icate vi ritroverete con l ' intestazione della mail

nella forma "[PATCH 2/5]")

git format-patch <since>..[<until>]

A meno che non specif ichiate - -stdout vi ritroverete tutti i dif f dei vari commit per arrivare da <since>

ad <until> (se quest'ultimo non è specif icato, pone di default i l ramo attuale); si può indicare per questi

sia i l loro codice hash che i l nome del branch che una tag. Ovviamente come si possono spedire le patch,

si possono anche " leggere" ed è qui che la potenzialità svetta:

git am <mail box>

apre la mail, scarica le patch e le applica. Per <mail box> si intende il percorso alla cartella locale della

mail (nella documentazione parlano di "Berkeley mail" che dovrebbe corrispondere alla posta letta

attraverso i l pacchetto mailx in un sistema Debian); nel mio caso è /var/log/packz se qualcuno ne sa di

più batta una mail ;- )

Consiglio di usare l 'opzione --interactive così da poter scegliere le patch da applicare (una alla volta!)

altrimenti vi dà errore (se non c i sono solo patch!!!), al massimo scarivatele a parte e poi applicatelo.

Comunque a meno che non siate dei guru installatevi pine (su ubuntu c 'è alpine) altrimenti diventate

rincoglioniti ad usare mail.

Nel caso non vogliate sc lerare è possibile applicare la patch manualmente tramite i l comando

git-applymbox <file della patch>


9 di 17 16/11/2008 22:56

e vi ritroverete i l commit già inserito nel tree con i l commento preceduto da "[PATCH]" per la gioia di

grandi e picc ini.

Nel caso non vi f idiate del vostro c l ient di posta è possibile uti l izzare git send-mail per avere con

sicurezza l ' invio della patch: quindi

git send-mail --to [email protected] --subject "vattela a prendere nel culo" files

Probabilmente non avete un servet SMTP quindi vi conviene installarvene uno af f inché i l tutto funzioni

per i l meglio: dalla documentazione di git si consiglia msmtp, un semplice programma che permette di

inviare patch anche attraverso connessioni che util izzano SSL (tipo gmail oppure autistic i ;- )): per

installarlo

# apt-get install msmtp

poi creare i l f i le ~/.msmtprc con per chi usa un account su autistic i

# Example for a user configuration file

# Set default values for all following accounts.

defaults

tls on

tls_starttls off

#tls_trust_file /etc/ssl/certs/ca-certif icates.crt

tls_certcheck off

logfile ~/.msmtp.log

# My email service

account packz

host smtp.autistic i.org

port 465

from [email protected]

auth on

user [email protected]

# if not set below, msmtp ask for a password

password

# Set a default account

account default : packz

e poi inviare la mail tramite

git send-email --smtp-server /usr/bin/msmtp file_contenente_la_patch

a quel punto vi verranno chieste interattivamente gli estremi della mail e le manderà in automatico.

Troubleshooting

A me personalmente non ha funzionato subito: ecco i possibili scenari

msmtp: /home/packz/.msmtprc: must have no more than user read/write permissions

Soluzione: chmod 0600 ~/.msmtprc

msmtp: the server sent an empty reply


10 di 17 16/11/2008 22:56

Soluzione: tls_starttls off (forse non la migliore...)

msmtp: TLS certif icate verification failed: the certif icate hasn't got a known issuer

Succede siccome il server usato (come per esempio autistic i), possiede un certif icato "self signed".

Soluzione: tls_certcheck off (sicurezza portami via)[per altre info]

Per usarlo con Gmail guardate nelle GitTips. Pubblicare il codice

Magari siete proprio voi ad avere la necessità di rendere pubblico i l codice e di rendere disponibile quindi

agli altri di poter c lonare i l vostro repository; esistono vari metodi per poterlo fare

HTTP

Di seguito le azioni da compiere

1) Spostarsi nella directory padre rispetto al vostro albero dei sorgenti (che deve essere già

"gittato");

i l progetto presuppongo sia in una directory chiamata "project"

2) eseguire git clone --bare project project.git

3) copiare la directory project.git nello spazio del web server

4) spostarsi nella directory appena copiata

5) Eseguire git --bare update-server-info

6) Rendere eseguibile lo script post-update tramite chmod a+x hooks/post-update nella directory

project.git.

Nel caso poi vogliate pubblicare su questo server le nuove modif iche del codice, basta eseguire tramite

ssh i l comando

git push ssh://mio.domino/absolute/path/to/git/project.git master:master

Git by Git

È possibile ottenere git attraverso git stesso con i l comando

git clone git://git.kernel.org/pub/scm/git/git.git

Consiglio caldamente di installare la versione più "moderna", magari tenendola parallelamente a quella

della vostra distro uf f ic iale: i passaggi da compiere sono i seguenti (tutti da eseguire come utente

normale)

git pull # aggiorna il tutto

git tag # per vedere l'ultima versione stabile (oppure gitk)

git checkout vx.x.x # pone il working tree a quella versione (no -rc please)

./configure --prefix=/opt/git-vx.x.x # imposta il path di installazione in /opt/ (createla

eventualmente)

make

make install

cd /opt/

unlink git # se avete già una precedente installazione manuale

ln -s git-vx.x.x git # crea il link simbolico

Aggiornate i l PATH in ~/.bashrc nella seguente maniera

PATH=/opt/git/bin/:$PATH


11 di 17 16/11/2008 22:56

e verif icate che git --version vi restituisca i l numeril lo giusto... nel caso interessi, la documentazione va

creata a parte con make doc, installata con make install-doc ricordandosi di impostare i l percorso di man

correttamente tramite la variabile MANPATH .

Configurazione

Un programma dalle così vaste potenzialità e comandi accessori, necessità di poter essere conf igurato a

livello utente come meglio si crede: a questo scopo sono possibil i due alternative

editare a mano il f i le .git/config1.

usare i l comando git config (usando assieme l'opzione --global viene impostato per tutti i repository

locali contenuti nel computer)

2.

Una possibil ità di vasta portata è la capacità di creare degli alias, c ioé dei nuovi comandi che eseguano

comandi di git e non: per impostarli basta creare una sezione alias nel f i le di conf igurazione (ulteriori

informazioni).

Cleanup&Optimize

Dopo aver lavorato per un certo periodo di tempo su un dato repository è possibile eseguire delle

operazioni di "pulizia" per tenere ordinato i l nostro archivio e diminuire lo spazio occupato su disco dallo

stesso. Il primo comando e git repack che riscrive tutti gli oggetti presenti nella directory (.git)/objects/

in una sottodirectory (.git)/objects/pack/ in un formato particolare (in pratica in una forma deltif icata,

per ulteriori info guardate Documentation/technical/pack-format.txt nell 'albero dei sorgenti di git). Il

sommo consiglia di ef fettuare i l repacking per non avere performance scadenti sul lungo periodo.

Appena creati i f i le *.pack comunque restano in giro gli oggetti originali (che a questo punto sono

rindondanti) e servirebbe dare un bel git-prune-packed, tuttavia pare un comando di basso l ivello ed è

quindi preferibile usare i comndi più general purpouse per la pulizia.

Per la pulizia del repository è consigliabile l 'uso di git gc che si preoccupa di chiamare a sua volta git

prune, i l quale è adibito ad eliminare ogni elemento non più accessibile (tramite git fsck --unreachable),

oltre che anche git-prune-packed come accennato sopra.

Anche l'occhio vuole la sua parte

Siccome è dif f ic i le seguire gli sviluppi del software facendo solo af f idamento ai commenti dei vari

commit, è disponibile i l progetto gitk, attualmente distribuito assieme a git stesso tramite cui è possibile

visualizzare l 'evoluzione del progetto che abbiamo a cuore: tramite le parole dello stesso Torvalds

possiamo dire

gitk is really quite inc redibly c ool, and is great for visualizing what is going on in a git repository. It's

espec ially useful when you are looking at what has changed sinc e a particular version, sinc e it grac efully

handles partial trees (and this also avoids the expense of looking at _all_ c hanges in a b ig projec t) .

(commit 5569bf9bbedd63a00780fc5c110e0cfab3aa97b9 di git ;- )), ma una immagine vale più di mille

parole


12 di 17 16/11/2008 22:56

questo è come si presenta visivamente i l progetto git a c irca metà del suo sviluppo: i rami di diverso

colore sono i vari branch...

Esistono tuttavia altri programmi analoghi che tuttavia non hanno la stessa resa graf ica: tig, qgit... se

approfondirò i l loro uti l izzo lo saprete.

Quando la rete non è available

Succede che non si ha a disposizione un accesso alla rete e quindi i comandi fetch/pull/push non possono

essere usati nella loro maniera convenzionale, nonostante questo git è ancora capace di essere

pienamente funzionale attraverso i l comando git bundle.

La sintassi del comando in questione è una delle seguenti

git-bundle create <file> <git-rev-list args>

git-bundle verify <file>

git-bundle list-heads <file> [refname...]

git-bundle unbundle <file> [refname...]

La prima versione è quella uti le per creare i l bundle: <file> corrisponderà al nome del f i le risultante e

<git-rev-list args> è un qualunque argomento accettabile da git-rev- l ist (quindi oltre sha1 si possono

usare tag e identif icativi temporali come " --since=10.days.ago"). Per creare semplicemente un bundle

con tutto l 'archivio si usa

git-bundle create my-project.bundle master

Nel f rattempo che imparo meglio leggetevi questo thread.

Packaging

In una certa misura è importante poter esportare i l proprio lavoro sotto forma di archivi da poter inviare

o da scaricare comodamente anche a chi non è un developer (developer developer) e proprio per questo

è stato inventato i l comando

git archive --format=<tar|zip> [--prefix=<prefix>/] <tree-ish> [path]

Poi per chi è un amante delle distribuzioni debian-based, esiste anche un insieme di comandi pensati

per interagire con i ri lasc i tramite pacchetti, inglobati nella suite git buildpackage

git import-dsc : crea un repository git da un pacchetto debian pre-esistente.


13 di 17 16/11/2008 22:56

git import-orig: crea un repository git da sorgenti.

git buildpackage: compila e crea i l pacchetto.

git dch: aggiorna i l Changelog a partire dai commit di git.

Esistono princ ipalmente due modi per iniziare ad usarlo

Importare un pacchetto pre-esistente: facc iamo un esempio con netcat

$ apt-get source netcat

$ git import-dsc

1.

Importare un progetto non avente un pacchetto debian:supponiamo che i l progetto sia archiviato in

un f i le project-0.2.tar.gz (attenzione che l 'archivio deve contenere un pref isso altrimenti i l

comando git import-orig restituirà un errore del tipo Cannot copy files: [Errno 20] Not a directory:

'../tmpnsjU34/NOME_DI_QUALCHE_FILE')

$ mkdir project-0.2

$ cd project-0.2

$ git init

$ git import-orig -u 0.2 /path/to/project-0.2.tar.gz

2.

In generale vengono usati due branch particolari

debian-branch: contiene i l ramo di lavoro dove vengono ef fettuati i lavori nel codice

upstream-branch: contiene l codice proveniente dalla upstream release (come tradurlo in italiano?)

tuttavi nulla vieta di cambiare la topologia del repository come meglio vi aggrada.

Per ulteriori informazioni andate sulla home page: http://honk.sigxcpu.org/projects/git-buildpackage

/manual-html/gbp.html.

Contributi

Esistono tutto un insieme di piccoli programmini accessori a git che si trovano sotto la directory

/usr/share/doc/git-core/contrib/; f ra questi vi segnalo nel bash_completion la possibil ità di avere i l

prompt con indicato i l branch in cui c i si trova (nel caso ovviamente la directory corrente corrisponda ad

un repo git)tramite __git_ps1: i l suo util izzo è tramite

PS1='$(__git_ps1 "%s branch")'

ovviamente potete aggiungere sia prima che dopo robe util i a voi...

Linkografia&Documentazione

wikipedia

home page del progetto (doc)

Linus Torvalds's technical speach (video)

Pagine di manuale (man git-<comando> oppure git <comando> --help)

Everyday git

git-buildpackage (home&doc)

Mail ing l ist archive (vecchia e nuova)

Bart's Blog (git tag)

Git for computer sc ientists (spiegazione tramite graf i di come lavora git a basso l ivello)

Git cheat sheet .

altro cheat sheet.

Git guide.

GitTips.

Repo pubblico per avere hosting di progetti gestiti tramite Git.

Post con considerazioni interessanti (sopratutto sull ' index).

Footnote

1 - In inglese viene chiamato distributed revision control software conf iguration management project.


14 di 17 16/11/2008 22:56

T h i s i s the Re Ca p tcha P l ug i n fo r Li fe ty pe

2 - Git in inglese è usato come insulto per riferirsi ad uno stupido.

3 - La versione nel sistema da me usato è la 1.4.4.2, mentre nella documentazione uf f ic iale c i si riferisce

alla 1.5 o successive, quindi i comandi potrebbero essere diversi; si può scaricare la versione unstable

per debian a questo indirizzo.

Trackback URL

http://noblogs.org/trackback.php?id=11115

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Please solve the puzzle (required)

Submit Comment

One Response to Git

Type the two words:


15 di 17 16/11/2008 22:56

packz says:

07/13,2007, at 00:07

Visit packz

Ma penso che questa situazione sia dif f ici le da gestire in quanto i l programma è stato pensatoappositamente per i sorgenti del kernel e quindi f i le di testo; io non sono un gran esperto e stoscrivendo a poco a poco le cose che imparo (tu mi sopravvaluti. . . ma grazie lo stesso per icomplimenti) e nel mio caso, quando sono presenti f i le binari ( immagini per esempio) l i tengo indirectory separate e poi le importo a parte: è meno f requente cambiare un immagine e di solito sene occupa una persona sola, io non so bene come sia i l tuo caso... se risolvi i l tuo problema o haiqualche consiglio sull 'uso di git non ti fare problemi a postarl i che l i aggiungo...

packz says:

09/27,2007, at 17:23

Visit packz


16 di 17 16/11/2008 22:56

Ho trovato questo delizioso l ink su del. icio.us su di un tipo che presenta una soluzione al tuoproblema

http://www.bluishcoder.co.nz/2007/09/git-binary-f i les-and-cherry-picking.html

fecendo uso di gitattributes (vedi http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html) appena ho tempo scrivo qualcosa, magari la traduzione della pagina dimanuale... se qualcun'altro ha soluzioni si faccia avanti.


17 di 17 16/11/2008 22:56

Self Improvement

Git