7.10 Ferramentas do Git - Depurando com Git

Se você rastrear um bug no seu código e quiser saber quando ele foi introduzido e por que, a anotação de arquivo (file annotation) é frequentemente sua melhor ferramenta. Ela mostra qual commit foi o último a modificar cada linha de qualquer arquivo. Então, se você ver que um método no seu código está com bugs, você pode anotar o arquivo com git blame para determinar qual commit foi responsável pela introdução daquela linha.

O exemplo seguinte usa git blame para determinar qual commit e committer foi responsável pelas linhas no Makefile de nível superior do kernel do Linux e, além disso, usa a opção -L para restringir a saída da anotação às linhas 69 a 82 daquele arquivo:

Note que o primeiro campo é o SHA-1 parcial do commit que modificou aquela linha por último. Os próximos dois campos são valores extraídos daquele commit — o nome do autor e a data de autoria daquele commit — para que você possa ver facilmente quem modificou aquela linha e quando. Depois disso vêm o número da linha e o conteúdo do arquivo. Note também as linhas de commit ^1da177e4c3f4, onde o prefixo ^ designa linhas que foram introduzidas no commit inicial do repositório e permaneceram inalteradas desde então. Isso é um pouco confuso, porque agora você já viu pelo menos três maneiras diferentes que o Git usa o ^ para modificar um SHA-1 de commit, mas é isso o que ele significa aqui.

Outra coisa legal sobre o Git é que ele não rastreia renomeações de arquivos explicitamente. Ele grava os snapshots e depois tenta descobrir o que foi renomeado implicitamente, após o fato. Uma das características interessantes disso é que você também pode pedir a ele para descobrir todos os tipos de movimento de código. Se você passar -C para o git blame, o Git analisa o arquivo que você está anotando e tenta descobrir de onde os trechos de código nele originalmente vieram, caso tenham sido copiados de outro lugar. Por exemplo, digamos que você está refatorando um arquivo chamado GITServerHandler.m em vários arquivos, um dos quais é GITPackUpload.m. Anotando o GITPackUpload.m com a opção -C, você pode ver de onde originalmente vieram seções do código:

Isso é realmente útil. Normalmente, você obtém como o commit original o commit onde você copiou o código para lá, porque essa é a primeira vez que você tocou nessas linhas neste arquivo. O Git diz qual foi o commit original em que você escreveu essas linhas, mesmo que isso tenha sido em outro arquivo.

Anotar um arquivo ajuda se você sabe, de início, onde o problema está. Se você não sabe o que está quebrando, e houveram dezenas ou centenas de commits desde o último estado em que você sabe que o código funcionou, você provavelmente vai recorrer ao git bisect por ajuda. O comando bisect faz uma pesquisa binária por todo o seu histórico de commits para ajudá-lo a identificar, o mais rápido possível, qual commit introduziu um problema.

Digamos que você acabou de dar push de uma release do seu código para um ambiente de produção, e você está recebendo relatos de bugs sobre algo que não estava acontecendo no seu ambiente de desenvolvimento, e você não consegue imaginar por que o código está fazendo isso. Você volta para o seu código e descobre que consegue reproduzir o problema, mas não consegue descobrir o que está dando errado. Você pode fazer um bisect do código para descobrir. Primeiro você roda git bisect start para dar o pontapé inicial, e depois você usa git bisect bad para dizer ao sistema que o commit atual no qual você está se encontra quebrado. Então, você tem que informar ao bisect qual foi o último estado sabidamente bom, usando git bisect good <commit_bom>:

O Git descobriu que houve cerca de 12 commits entre o commit que você marcou como o último commit bom (v1.0) e a atual versão ruim, e fez checkout daquele bem no meio para você. A esta altura, você pode rodar o seu teste para ver se o problema existe na época deste commit. Se ele existir, então ele foi introduzido em algum momento antes deste commit intermediário; se ele não existir, então o problema foi introduzido em algum momento após o commit intermediário. Vê-se que não há nenhum problema aqui, e você conta isso para o Git digitando git bisect good e prossegue na sua jornada:

Agora você está em um outro commit, bem no meio do caminho entre o que você testou por último e o seu commit ruim. Você roda o teste novamente e constata que este commit está quebrado, então você informa isto ao Git usando git bisect bad:

Este commit está bom, e agora o Git tem toda a informação que ele precisa para determinar onde o problema foi introduzido. Ele te dá o SHA-1 do primeiro commit ruim (bad commit) e mostra algumas das informações do commit e quais arquivos foram modificados nesse commit, para que você possa descobrir o que aconteceu que possivelmente causou este bug:

Quando você terminar, você deve rodar git bisect reset para resetar seu HEAD de volta para onde você estava antes de você ter começado, ou você vai terminar em um estado estranho:

Esta é uma ferramenta poderosa que pode ajudar você a checar centenas de commits à procura de um bug introduzido, em minutos. De fato, se você tiver um script que vai dar exit com 0 caso o projeto seja bom ou não-0 caso o projeto seja ruim, você consegue automatizar o git bisect completamente. Primeiro, mais uma vez você tem que determinar o escopo do bisect informando os commits conhecidos bom (good) e ruim (bad). Você pode fazer isso listando-os com o comando bisect start se quiser, primeiro o commit ruim e depois o bom:

Ao fazer isso o Git executa automaticamente o script test-error.sh a cada commit extraído até ele encontrar o primeiro que está com problema. Você pode ainda, usar comandos, tais como, make ou make tests ou até mesmo um script qualquer para a execução automatizada dos testes.