Git é um sistema de controle de versões utilizado no desenvolvimento de código. Caso um bug tenha aparecido em um sistema que está sendo desenvolvido, com o apoio do Git é possível identificar qual commit foi responsável por este bug, com o auxílio de um comando.
Este comando é o:
GabaritoA — git-bisect
Gabarito: letra A. O comando git bisect é a ferramenta do Git projetada exatamente para localizar, por busca binária no histórico, o commit que introduziu uma regressão (bug). O git blame mostra quem alterou cada linha de um arquivo, mas não faz a varredura automática do histórico para achar o commit culpado — é essa distinção que decide a questão.
O Git é um sistema de controle de versão distribuído que trata os dados como um conjunto de imagens (snapshots) do sistema de arquivos. Cada commit recebe um ID exclusivo de 40 caracteres (soma SHA-1) e o Git não remove dados, apenas adiciona novas versões. Quando um bug aparece, o desenvolvedor precisa descobrir qual alteração o causou. É aí que entram os comandos de investigação de histórico.
O git bisect funciona como uma busca binária: você informa um commit bom (onde o bug não existia) e um commit ruim (onde o bug está presente). O Git então faz um checkout automático de um commit intermediário, e você testa se o bug está presente ou não naquele ponto. Com base na sua resposta, o Git descarta metade do histórico e repete o processo, até isolar exatamente o commit que introduziu o problema. É o comando ideal para o cenário descrito no enunciado.
O git blame é frequentemente confundido com o bisect, mas tem função diferente: ele mostra, linha por linha de um arquivo, qual commit foi o último a modificar aquela linha e quem o fez. É útil para saber quem alterou uma linha específica, mas não faz a busca automática no histórico — você precisa saber qual arquivo e qual linha investigar. O git grep busca texto dentro dos arquivos do repositório; o git status mostra o estado do diretório de trabalho e da área de preparo; e o git tag cria marcadores (tags) em commits específicos, geralmente para releases.
A pegadinha da banca está em trocar o comando que faz a busca automática no histórico (bisect) pelo comando que apenas atribui autoria a linhas (blame). Guarde a fronteira: bisect = busca binária para achar o commit que introduziu o bug; blame = autoria de linhas específicas.
O git bisect é o comando que permite identificar, por busca binária, qual commit introduziu um bug. O processo é: marcar um commit bom e um ruim, e o Git testa commits intermediários até isolar o culpado. É exatamente o que o enunciado descreve: "identificar qual commit foi responsável por este bug".
O git blame mostra, para cada linha de um arquivo, qual commit a modificou pela última vez e quem o fez. Ele atribui autoria a linhas específicas, mas não faz a busca automática no histórico para encontrar o commit que introduziu um bug. O candidato que confunde os dois cai na pegadinha: o blame é útil para saber quem alterou uma linha, mas não para a varredura binária que o bisect faz.
O git grep busca por padrões de texto dentro dos arquivos do repositório, similar ao comando grep do Linux. Ele não tem relação com a identificação de commits que introduziram bugs — serve para localizar onde uma string aparece no código.
O git status mostra o estado atual do diretório de trabalho e da área de preparo (staging area): quais arquivos foram modificados, quais estão preparados para commit e quais não são rastreados. Não realiza nenhuma análise de histórico.
O git tag cria marcadores (tags) em commits específicos, geralmente para marcar versões de release (v1.0, v2.0 etc.). Não tem função de investigação de bugs.
Para diferenciar na prova, lembre-se: bisect = busca binária ("bi" de binário) para achar o commit culpado; blame = culpa/autoria de linhas. Se a questão falar em "identificar qual commit introduziu o bug", é bisect. Se falar em "quem alterou esta linha", é blame.
Gabarito: letra A
Link permanente: /questoes/vu196553