APRENDER. PRATICAR. EVOLUIR.Definir a propriedade antes da pesquisa
O laboratório da aula anterior também cria nove commits, identificados didaticamente por revisões 0 a 8. Cada um guarda um JSON com revision e result. Até à revisão 4, result é good; desde 5, é bad. Um oráculo externo ao working tree lê esse ficheiro e devolve um código de saída. Este fixture não compila uma aplicação: demonstra um contrato de classificação sobre uma propriedade construída. O runner executa o oráculo na revisão 0 e na 8 antes de iniciar a pesquisa. Num problema real, regista o comando, dados de entrada, dependências e resultado esperado que fazem os extremos serem comparáveis. Se uma API externa muda de comportamento durante a pesquisa, controla essa dependência ou explica a incerteza. Não uses apenas a data de uma release para declarar que era boa.
Ler códigos sem esconder falhas do ambiente
No modo normal, o oráculo devolve 0 para good e 1 para bad. A pesquisa identifica a revisão 5. No modo skip, as revisões 4, 5 e 6 devolvem 125 porque o exercício as torna não testáveis. O resultado deixa candidatos 4, 5, 6 e 7: o laboratório não tem informação suficiente para um único culpado. No terceiro modo, o script devolve 128 para interromper a automação. Estes ramos ensinam a distinguir propriedade falsa, propriedade desconhecida e falha que exige parar. Um wrapper que deixa escapar 127 por ferramenta inexistente pode produzir uma classificação bad indevida; valida pré-condições antes de medir a regressão. O caso Delta pede a reposição do ambiente de teste para estreitar o intervalo, sem inventar good para revisões que não compilaram. Guarda os resultados desconhecidos com a razão concreta.
Guardar decisões e voltar ao ponto de partida
O runner guarda bisect log fora do repositório, faz reset e confirma main no commit original. Depois usa replay e confirma que as classificações guardadas reconstituem a conclusão. Replay não volta a executar o oráculo automaticamente. É possível repetir uma conclusão histórica mesmo depois de as dependências mudarem, razão pela qual o caso Lago exige distinguir reconstrução e nova medição. Guarda IDs completos, versão do teste, janela e ambiente com o log. O oráculo também fica fora do working tree para não desaparecer quando bisect visita commits antigos. Ao terminar cada ramo, o laboratório limpa o estado de bisect e confirma a branch e o working tree. Estas verificações evitam deixar o próximo operador num checkout intermédio sem perceber porquê. Não é necessário publicar qualquer referência para conservar localmente o diagnóstico.
Converter diagnóstico em decisão operacional
O guião de quarenta minutos abaixo combina os casos Âncora, Cedro, Delta e Lago. Tem dados e respostas esperadas, mas ainda não foi executado com participantes. Dedica dez minutos às referências e ao lease, dez ao pruning, dez ao oráculo e dez ao handover. Entrega um mapa de referências, uma lista de dados a preservar, um intervalo com classificações e uma recomendação operacional com condições. A revisão 5 é a primeira bad no fixture normal; isso não aprova uma reversão de uma aplicação bancária. Uma mitigação real deve considerar contratos de dados, dependências, consumidores e processo de mudança. O laboratório executou Git 2.50.1; novas opções que aparecem no manual atual não foram automaticamente testadas. Mantém as lacunas visíveis: compatibilidade funcional, alojamento, permissões, execução em 2.56 e revisão especializada. O valor da investigação está numa conclusão reproduzível com limites precisos.
GUIÃO ÂNCORA / CEDRO / DELTA / LAGO, 40 minutos
Dados fictícios. Não usar comandos de reescrita em remotos reais.
0–10: O tem dois descendentes, C e L. A reviu O. Remoto=C; HEAD de A=L; origin/main=C após fetch. Escreve a expectativa e o passo de revisão.
Resposta: a decisão anterior referia O. Um lease explícito contra O rejeita. Rever C antes de renovar qualquer decisão; um lease contra C pode aceitar L sem incluir C.
10–20: B tem origin/temporary, retained e tag local-only em O. temporary é apagada no remoto. Compara fetch --prune normal com a proposta que acrescenta --prune-tags.
Resposta: no ensaio normal, desaparece a referência de acompanhamento; branch e tag locais permanecem. Não generalizar a opções/refspecs que incluam tags. Preservar referências necessárias antes de limpeza autorizada.
20–30: Revisões 0–4 good; 5–8 bad. Primeiro oráculo devolve 0/1. Segundo devolve 125 para 4–6. Terceiro devolve 128.
Resposta: primeiro isola 5; segundo deixa 4–7 como candidatos; terceiro interrompe a automação. Não classificar desconhecidos como good. Executável em falta pode devolver 127 e contaminar a classificação.
30–40: O turno seguinte faz replay, mas mudou a imagem de build. Lista evidências e ações de handover.
Resposta: guardar IDs, log, versão do oráculo e ambiente; distinguir replay de nova execução; repetir testes relevantes e rever mitigação e contratos de dados. Confirmar reset para main e working tree limpo.
Entregas: mapa de referências, âmbito de retenção, tabela de classificações e recomendação com pendências.
Estado: exercício editorial, ainda não realizado com participantes.Com o oráculo normal, a revisão 5 é isolada. Ao saltar 4–6, a conclusão passa a incluir 4–7 e exige nova evidência.
Armadilhas comuns
Marcar falhas de ambiente como regressões; guardar o teste apenas num commit recente; confundir replay com execução; responsabilizar alguém sem isolar a causa.
Tópicos relacionados: Diagnóstico e releases · Backports e dependências · Handover L3
Uma pesquisa útil precisa de um oráculo fiável, extremos demonstrados e um relatório que conserve a incerteza restante.
Referência: Git bisect 2.50.0 manual · Git 2.56; workflow concepts compatible with modern Git 2.x