Conceito e mecanismo
Um identificador de commit permite referenciar um estado da história, mas a aplicação implantada também depende do processo de build, configuração e dependências. Regista a relação entre commit, artefacto e implantação. Uma branch móvel não identifica de forma estável o conteúdo de uma release passada. Uma tag pode ajudar a nomear uma versão, mas a governação precisa de definir se pode ser alterada e como verificar a origem do artefacto.
Aplicação guiada
Bisect ajuda a reduzir uma regressão entre uma referência conhecida como boa e outra como má, avaliando versões intermédias. O teste usado deve representar a falha e ser suficientemente determinístico. Se uma versão não puder ser avaliada, não a marques como boa apenas para avançar; usa a decisão de skip quando apropriada e reconhece possível ambiguidade no resultado. Se o ambiente muda entre execuções, separa o efeito do código de configuração, dados e dependências. Um teste intermitente pode conduzir a uma classificação errada.
A exportação começou a falhar entre duas releases. Reproduz a mesma amostra e fixa a configuração num ambiente de exercício antes de classificar cada commit no bisect.
Armadilhas comuns
Tratar a branch main como prova da versão implantada; marcar um commit não testável como good; concluir causalidade apenas por proximidade temporal.
Tópicos relacionados: Working tree, index e commit · Branches, merge e rebase
Uma investigação precisa de versões identificadas e de um critério de falha reproduzível.
Referência: Git: isolating regressions · Git 2.56; workflow concepts compatible with modern Git 2.x