>>Tue, 11 Apr 2006 22:29:23 +0200

devel : Tutorial de GIT

Continuant la saga de tutorials de sistemes de control de versions, aqui vé la segona entrega: GIT.

Fa uns messos vaig començar a provar sistemes de control de versions distribuits, després d'algunes proves amb gnuarch i git, vaig acabar decantant-me per GIT, ja que GNUarch actualment està un pel verd en alguns aspectes, per sort farà dos messos que van canviar de maintainer i el nou (TomLord->AndiTai) i en molt poc temps ha arreglat gran quantitat de bugs i ha afegit bastantes noves features. De fet avui mateix ha tret un release nou.

La proxima guia serà sobre gnu-arch

Sistemes distribuits

La gracia de fer servir un sistema de control de versions distribuit es que podem treballar offline i podem facilitar bastant el desenvolupament paral·lel.

Una cosa intereessant de gnu-arch ens permet per exemple fer 'undo' i 'redo' en el source-tree, per exemple. O podem tenir N branques del nostre codi i canviar de branca instantaniament.

Quan treballem amb un sistema de control de versions distribuit (scvd a partir d'ara) tindrem el repositori en local, i quan volguem publicar els canvis que hem fet haurem de pujar/sincronitzar el repo local a un directori public HTTP o accesible per sftp, etc..

A mi per exemple, es algo que em facilita bastant la feina, ja que normalment treballo cada dia amb 3 ordinadors a casa i amb GIT m'es bastant més facil poder sincronitzar canvis entre elles, i evitar-me tota la feinada d'arreglar parches a manija pq encaixin a la versió del repositori, etc.

GIT itself

Com segurament sabreu Linux ha estat desenvolupat sobre un sistema de control de versions privatiu (BitKeeper) i l'escusa que donaven era que no hi havia cap alternativa lliure al seu nivell.

Doncs bé, bitkeeper tenia una llicencia gratuita del programa client i veient la gran quantitat de pasta que estaven perdent (o no guanyant) al tenir una llicencia gratuita...doncs van decidir treure-la i fer-ho tot de pago.

Linus es va cabrejar (obviament), encara que era logic que una empresa fes aixo... i va decidir (enlloc de millorar algo existent) fer un sistema de control de versions from scratch en plan *NIX, es a dir...mil programes (112 per ser exactes) petitons que juntant-los surten coses guais

Començant un projecte amb GIT

Probablement ens moli utilitzar GIT per un projecte ja començat amb SVN, CVS o GNUARCH... en una sola linea:

console:

$ git-cvsimport -v -d <cvsroot> -C <destination-path> <module-name>

En canvi si volem començar desde zero:

console:

$ mkdir hello & cd hello $ echo "Hello World" > hello.message $ ls hello.message $ git-init-db defaulting to local storage area $ git-ls-files (...) # no files yet $ git-add * $ git-ls-files hello.message

Ens guardara un tracking dels fitxers a ./.git/:

console:

$ find .git/ -type f .git/hello .git/index .git/config .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a

Setup del repositori

Aixo no es necessari, pero no esta gens malament que definim certes dades sobre el projecte, com el nostre nom i correu:

console:

$ git-repo-config user.name "pancake" $ git-repo-config --get user.name pancake $ git-repo-config user.email "pancake@mailinator.com" $ git-repo-config --get user.email pancake@mailinator.com

Manejant els fitxers

Com ja hem vist, per afegir un fitxer al repositori hem de fer servir "git-add". Que no te gaires secrets

Pero obviament podrem fer diferentes operacions basiques facilment:

· git-add/files/ : afegeix fitxers al repostori.

· git-update-index/files/ : marca els fitxers a comitejar.

· git-mv/orig/ /dest/ : movem el fitxer dins del repositori i en el directori del projecte.

· git-update-index --remove : marquem un fitxer per borrar del repositori.

I finalment:
· git-commit : commitejem els canvis al repo local.

Podem fer 'cat's dels fitxers del repositori d'una certa versió, d'una forma bastant esoterica

console:

$ echo BlowMeAgain > hello.message $ git-ls-files --stage 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 hello.message $ git-cat-file blob ce013625030ba8dba906f756967f9e9ca3944 Hello World $ git-update-index hello.message $ echo Whoooops > hello.message $ git-ls-files --stage 100644 6fc81e374b9de4ea858c52a7efaaf4ebbcb3c9a8 0 hello.message $ git-cat-file blob 6fc81e374b9de4ea858c52a7efaaf4ebbcb3c9a8 BlowMeAgain $ cat hello.message Whoooops

Per pillar el SHA1, podem fer-ho amb 'git-hash-object':

console:

$ git-hash-object hello.message 6fc81e374b9de4ea858c52a7efaaf4ebbcb3c9a8

Movent-nos entre branques..

Una cosa molt guapa del GIT es que ens permet mourens omlt rapidament entre branques del projecte, basicament perque es una de les seves principals virtuts

.

GIT, al mantenir una base de dades amb SHA1 de tots els fitxers comprimits, ens permet fer canvis molt rapids sobre el directori de treball a partir del repositori. Aixo ens pot ser util per crear branques de desenvolupament per afegir certes features que no volem que estiguin a la branca principal fins que no estiguin acabades, i en tot cas si algu vol utilitzar-les només ha de decidir quina branca vol utilitzar. Aixi de simple

console:

$ echo "Hello World" > hello.message $ git-update-index hello.message $ git-commit -m "* (hello.message): initial hello world" # creem una revisió master $ git-branch # llistem les branques * master $ git-branch development # creem una nova branca $ git-branch development * master $ git-checkout -f development # canviem a la branca 'development' $ git-branch * development master # fem alguns canvis en aquesta branca.. $ echo FooIsAHappyCow > hello.message $ git-update-index hello.message $ git-commit -m "* (hello.message): Minor syntax change." # Amb aixo podem veure si hi ha algo per comitejar $ git-status nothing to commit # I mirem les diferencies amb l'altre branca: $ git-diff master..development diff --git a/hello.message b/hello.message index 6fc81e3..8a8f969 100644 --- a/hello.message +++ b/hello.message -Hello World +FooIsAHappyCow

També podem manejar TAGs per fer marques en certs estats del repositori dins d'una branca:

console:

$ git tag "2.0stable"

Logs

console:

$ PAGER=cat git log commit c08618e3e6a763014a15676a9981109398618016 Author: <pancake@mailinator.com> Date: Tue Apr 11 21:53:35 2006 +0200 * (hello.message): initial hello world" commit 0f114c58a1169e0910af45cc728f810344fd5779 Author: <pancake@mailinator.com> Date: Tue Apr 11 21:42:34 2006 +0200 * (hello.message): Minor syntax change."

Podem fer servir també la comanda git-whatchanged, per veure el output de l'ultim canvi sobre un fitxer, és a dir: el log-message i el diff-patch:

console:

$ PAGER=cat git-whatchanged -p hello.message Author: <pancake@mailinator.com> Date: Tue Apr 11 21:42:34 2006 +0200 * (hello.message): Minor syntax change." diff --git a/hello.message b/hello.message index 6fc81e3..8a8f969 100644 --- a/hello.message +++ b/hello.message -Hello World +FooIsAHappyCow

Publicant els repositoris

Aquesta es potser la part més complicada d'entendre quan passem d'un sistema centralitzat a un distribuit.

Nosaltres sempre treballarem sobre un respositori local, tot el que fem mai serà publicat en una maquina remota, aixo ens permet separar millor els stages de producció i treballar més rapidament (local/remot).

El fet de publicar repositoris no es considera una tasca propia de GIT, aixi que s'ajuda amb altres comandes com rsync per exemple.

El primer que haurem de fer es crear el directori on penjarem el nostre repositori public. Si ho deixem penjat d'un directori accessible per HTTP o GIT, podrem oferir acces anonim. Sino, també podem servir-lo a través de SSH.

console:

$ ssh host host$ mkdir -p /path/to/project.git/ host$ cd /path/to/project.git/ host$ git-init-db host$ git-update-server-info host$ ^D

Després simplement haurem de sincronitzar els directoris local i remot:

console:

$ rsync -az .git/* user@host:/path/to/project.git/.git/

Pillant repos

Si volem fer un checkout d'un repositori d'algú, ho haurem de fer amb git-clone.

Aquesta comanda ens permet fer un fetch desde http, ssh o un protocol propi (usant git-shell)

Aixi per exemple descargariem el gDVB:

console:

$ git-clone http://news.nopcode.org/gdvb.git/.git/ defaulting to local storage area got c901702e6e846029d99254c6b31fe5b2e99cb906 walk c901702e6e846029d99254c6b31fe5b2e99cb906 got 97d557002c9bcdd81237fc5117e9f683ca338323 got 5d1d838d999c74d9fef5876292f5a2c126cf8ea2 (...) $ ls -F gdvb.git/ $ cd gdvb.git $ git-branch devel * master origin $ git-checkout -f devel $ cat .git/remotes/origin URL: http://news.nopcode.org/gdvb.git/.git/ Pull: master:origin Pull: devel:devel

Si volem un equivalent al "cvs up -dP", es a dir, actualitzar el repositori local a partir d'un repositori remot:

console:

$ git-pull

Si hem fet modificacions als fitxers, segurament no ens deixi fer un pull correctament, aixi que ho podem mirar amb un git-whatchanged guardar els canvis que haguem fet o esborrar-los, resetejant els objectes al seu ultim estat en el repositori:

console:

$ git-reset

Frontend Web

Al igual que altres sistemes de control de versions tenen frontends web (cvsweb, darcsweb, etc..) GIT tb en tè, i s'en diu: gitweb.

Es un sol script en perl, que hem d'editar per configurar el path cap als nostres repositoris, ..

Aqui podeu veure el meu repositori de GIT:

>> gitweb de pancake.nopcode

Podeu descarregar el gitweb d'aqui:
>> gitweb.cgi

URLs

>> GIT homepage
>> GIT tarballs

[add comment] [view comments] (5)