debugging.asc

Depuració amb Git

A més de ser principalment per al control de versions, Git també proporciona algunes comandes per ajudar-te a depurar els teus projectes de codi font. Com que Git està dissenyat per gestionar gairebé qualsevol tipus de contingut, aquestes eines són bastant genèriques, però sovint poden ajudar-te a buscar un error o culpable quan les coses van malament.

Anotació de fitxers

Si localitzes un error en el teu codi i vols saber quan es va introduir i per què, l’anotació de fitxers sovint és la teva millor eina. Et mostra quina confirmació va ser l’última a modificar cada línia de qualsevol fitxer. Així que si veus que un mètode en el teu codi té un error, pots anotar el fitxer amb git blame per determinar quina confirmació va ser responsable de la introducció d’aquella línia.

El següent exemple utilitza git blame per determinar quina confirmació i confirmador va ser responsable de les línies al fitxer Makefile de nivell superior del nucli de Linux i, a més, utilitza l’opció -L per restringir la sortida de l’anotació a les línies 69 a 82 d’aquest fitxer:

$ git blame -L 69,82 Makefile
b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line")
b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 70)   KBUILD_VERBOSE = $(V)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 71) endif
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 72) ifndef KBUILD_VERBOSE
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 73)   KBUILD_VERBOSE = 0
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 74) endif
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 75)
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 76) ifeq ($(KBUILD_VERBOSE),1)
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 77)   quiet =
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 78)   Q =
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 79) else
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 80)   quiet=quiet_
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 81)   Q = @
066b7ed955808 (Michal Marek   2014-07-04 14:29:30 +0200 82) endif

Observa que el primer camp és el SHA-1 parcial de la confirmació que va modificar per última vegada aquesta línia. Els dos camps següents són valors extrets d’aquesta confirmació: el nom de l’autor i la data d’autorització d’aquesta confirmació, de manera que pots veure fàcilment qui va modificar aquesta línia i quan. Després d’això, ve el número de línia i el contingut del fitxer. També nota les línies de confirmació ^1da177e4c3f4, on el prefix ^ designa línies que es van introduir en la confirmació inicial del repositori i han romàs sense canvis des de llavors. Això és una mica confús, perquè ara has vist almenys tres maneres diferents en què Git utilitza el ^ per modificar un SHA-1 de confirmació, però això és el que significa aquí.

Una altra cosa interessant de Git és que no segueix els canvis de nom de fitxers de manera explícita. Registra les instantànies i després intenta esbrinar què es va canviar de nom de manera implícita, després del fet. Una de les característiques interessants d’això és que pots demanar-li que esbrini tot tipus de moviment de codi també. Si passes -C a git blame, Git analitza el fitxer que estàs anotant i intenta esbrinar d’on van venir originalment els fragments de codi dins d’ell si es van copiar d’alguna altra part. Per exemple, diguem que estàs refactoritzant un fitxer anomenat GITServerHandler.m en múltiples fitxers, un dels quals és GITPackUpload.m. En culpar GITPackUpload.m amb l’opció -C, pots veure d’on van venir originalment les seccions del codi:

$ git blame -C -L 141,153 GITPackUpload.m
f344f58d GITServerHandler.m (Scott 2009-01-04 141)
f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 145)
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 146)         NSString *parentSha;
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 147)         GITCommit *commit = [g
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 148)
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 149)         //NSLog(@"GATHER COMMI
ad11ac80 GITPackUpload.m    (Scott 2009-03-24 150)
56ef2caf GITServerHandler.m (Scott 2009-01-05 151)         if(commit) {
56ef2caf GITServerHandler.m (Scott 2009-01-05 152)                 [refDict setOb
56ef2caf GITServerHandler.m (Scott 2009-01-05 153)

Això és realment útil. Normalment, obtens com a confirmació original la confirmació on vas copiar el codi, perquè és la primera vegada que vas tocar aquestes línies en aquest fitxer. Git et diu la confirmació original on vas escriure aquestes línies, fins i tot si era en un altre fitxer.

Cerca binària

Anotar un fitxer ajuda si saps on està el problema des del principi. Si no saps què està fallant, i hi ha hagut desenes o centenars de confirmacions des de l’últim estat on saps que el codi funcionava, probablement recorrereu a git bisect per obtenir ajuda. La comanda bisect fa una cerca binària a través del teu historial de confirmacions per ajudar-te a identificar el més ràpid possible quina confirmació va introduir un problema.

Diguem que acabes de llançar una versió del teu codi a un entorn de producció, estàs rebent informes d’errors sobre alguna cosa que no passava al teu entorn de desenvolupament, i no pots imaginar per què el codi està fent això. Tornes al teu codi, i resulta que pots reproduir el problema, però no pots esbrinar què està anant malament. Pots fer una cerca binària al codi per esbrinar-ho. Primer executes git bisect start per començar, i després utilitza git bisect bad per dir-li al sistema que la confirmació actual en la qual ets està trencada. Llavors, has de dir-li a bisect quan va ser l’últim estat conegut com a bo, utilitzant git bisect good <good_commit>:

$ git bisect start
$ git bisect bad
$ git bisect good v1.0
Bisecting: 6 revisions left to test after this
[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] Error handling on repo

Git va esbrinar que aproximadament 12 confirmacions van venir entre la confirmació que vas marcar com l’última bona confirmació (v1.0) i la versió dolenta actual, i va comprovar la del mig per a tu. En aquest punt, pots executar la teva prova per veure si el problema existeix a partir d’aquesta confirmació. Si ho fa, llavors es va introduir en algun moment abans d’aquesta confirmació mitjana; si no ho fa, llavors el problema es va introduir en algun moment després de la confirmació mitjana. Resulta que no hi ha cap problema aquí, i li dius a Git que escriguis git bisect good i continuïs el teu camí:

$ git bisect good
Bisecting: 3 revisions left to test after this
[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] Secure this thing

Ara ets en una altra confirmació, a meitat de camí entre la que acabes de provar i la teva confirmació dolenta. Executes la teva prova una altra vegada i descobreixes que aquesta confirmació està trencada, així que li dius a Git que escriguis git bisect bad:

$ git bisect bad
Bisecting: 1 revisions left to test after this
[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] Drop exceptions table

Aquesta confirmació està bé, i ara Git té tota la informació que necessita per determinar on es va introduir el problema. Et diu el SHA-1 de la primera confirmació dolenta i mostra alguna informació de la confirmació i quins fitxers es van modificar en aquesta confirmació per tal que puguis esbrinar què va passar que podria haver introduït aquest error:

$ git bisect good
b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04
Author: PJ Hyett <pjhyett@example.com>
Date:   Tue Jan 27 14:48:32 2009 -0800

    Secure this thing

:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M  config

Quan hàgis acabat, hauries d’executar git bisect reset per restablir el teu HEAD a on estaves abans de començar, o acabaràs en un estat estrany:

$ git bisect reset

Aquesta és una eina potent que et pot ajudar a comprovar centenars de confirmacions per un error introduït en minuts. De fet, si tens un script que sortirà amb 0 si el projecte està bé o amb un valor diferent de 0 si el projecte està malament, pots automatitzar completament git bisect. Primer, li dius de nou l’abast de la cerca binària proporcionant les confirmacions conegudes com a dolentes i bones. Pots fer això llistant-les amb la comanda bisect start si vols, llistant la confirmació coneguda com a dolenta primera i la confirmació coneguda com a bona segona:

$ git bisect start HEAD v1.0
$ git bisect run test-error.sh

Fent això s’executa automàticament test-error.sh en cada confirmació comprovada fins que Git troba la primera confirmació trencada. També pots executar alguna cosa com make o make tests o el que sigui que tens que executa proves automatitzades per a tu.