Gerrit, git e revendo todo o ramo

8

Agora estou aprendendo o Gerrit (que é a primeira ferramenta de revisão de código que eu uso). A Gerrit requer uma alteração revisada para consistir em uma única confirmação. Meu ramo de recursos tem cerca de 10 confirmações.

A maneira preferida pelo gerrit é esmagar esses 10 commits em um único. No entanto, dessa maneira, se a consolidação for mesclada na ramificação de destino, o histórico interno dessa ramificação de recurso será perdido. Por exemplo, não poderei usar git-bisectpara dividir esses commits. Estou certo?

Estou um pouco preocupado com esse estado de coisas. Qual é a justificativa para essa escolha? Existe alguma maneira de fazer isso em Gerrit sem perder a história?

git code-reviews gerrit

— liori
fonte

1

isso pode ser mais apropriado no stackoverflow

1

Eu não tenho nenhuma experiência com Gerrit. Eu usei o Atlassian FishEye + Crucible e ele não tem essa restrição. Pode ser possível adicionar confirmações adicionais a uma única revisão? Talvez você precise fazer isso manualmente.

— Andrew T Finnell

Até onde eu sei, a Gerrit não suporta a revisão de uma filial. Ele suporta apenas a revisão e aprovação de um único patch de cada vez. E eles afirmam que é um recurso, não um bug. Não concordo e estou procurando uma ferramenta que possa revisar uma ramificação como um todo e aprovar atomicamente a ramificação ou desaprovar a ramificação inteira (e ainda obter comentários por patch / linha).

— Mikko Rantalainen

2

A revisão de código tem o melhor impacto quando é um gancho de pré-confirmação (pré-envio no caso de git). Se um erro encontrado no dia 5 dos seus dez confirma, como você o corrige (preservando o histórico)? Claro, você pode criar outro ramo de tópico, corrigir esse commit, escolher os 5 commits restantes e reenviar os diffs para revisão, mas isso é muito complexo (embora você possa escrever um script para ele).

As alterações feitas em um único repositório devem, idealmente, preservar seu estado (por exemplo, não interromper a compilação, testes etc.). Portanto, se suas alterações forem feitas dessa maneira, elas poderão ser revisadas separadamente, caso contrário, compactá-las seria melhor do que sair do repositório inconsistente.

Você pode criar um erro no rastreador de erros e colocar uma referência em cada confirmação, para que os revisores e futuros leitores saibam o que você está tentando alcançar no seu conjunto.

— vissi
fonte

2

“Como você o consertaria” - erros acontecem e, por enquanto, bastava corrigir o problema em qualquer uma das confirmações posteriores, desde que a ramificação mestre no servidor central nunca apontasse diretamente para qualquer confirmação entre bug e consertar. Portanto, nesse caso, eu colocaria uma correção como décima primeira confirmação no ramo revisado. Esse método é uma coisa ruim?

— Liori

1

E quanto à integração contínua? você fez 10 confirmações em uma ramificação de recursos e ela será "publicada" de uma só vez - isso seria um grande impacto para outras pessoas que deveriam revisar essas confirmações / alterações.

No entanto, vale a pena enviar 10 confirmações, se as confirmações contiverem modificações de código separadas. Porém, caso as confirmações contenham modificações contínuas em um único recurso (portanto, a maioria das confirmações apenas correções ou status intermediário de uma implementação contínua de uma definição de função), é melhor agrupá-las em uma única confirmação.

Em geral, pense na opinião dos revisores - qual é o tamanho de uma modificação de código que pode ser revisada facilmente.

Nota: O Gerrit não serve apenas para revisar o código - as alterações devem acionar vários testes de aceitação. (teste de unidade, teste de fumaça) Portanto, se você os tiver, será mais difícil publicar códigos com defeito. Portanto, dessa perspectiva, um commit deve conter essas alterações que valem a pena testar.

Então, Gerrit força você a não cometer mudanças muito pequenas e muito grandes. (você usará --amendnão apenas para corrigir uma alteração já enviada para a Gerrit, em vez de corrigir uma confirmação que deseja enviar para revisão)

— Laplasz
fonte