Revisão de código Gerrit, ou modelo de garfo e puxa do Github?

Estou iniciando um projeto de software que será desenvolvido em equipe e comunidade. Eu já havia sido vendido no gerrit, mas agora o modelo de solicitação de garfo e tração do Github parece quase fornecer mais ferramentas, maneiras de visualizar confirmações e facilidade de uso.

Para alguém que tem pelo menos um pouco de experiência com ambos, quais são os prós / contras de cada um e quais seriam melhores para um projeto em equipe que deseja deixar em aberto a possibilidade de desenvolvimento da comunidade?

— user1366476
fonte

A principal diferença entre os fluxos de trabalho do Gerrit e do GitHub é como as mudanças são modeladas.

No Gerrit, todo commit é uma mudança independente. Embora a Gerrit mostre as relações entre as confirmações, as revisões são realizadas por confirmação. As equipes que são boas em dividir grandes alterações em pequenas confirmações independentes provavelmente terão mais sucesso com a Gerrit. No entanto, como o modelo da Gerrit inclui revisões sucessivas de um commit específico, ele incentiva os fluxos de trabalho do Git aos quais muitos desenvolvedores não estão acostumados, como alterar um commit anterior e pressioná-lo novamente ou compactar um conjunto crescente de commits de uma ramificação de tópico em um único cometer, entregar.

No Github, uma solicitação pull modela um relacionamento entre duas ramificações. O fluxo de trabalho esperado no Github é confirmar uma ou mais alterações em uma ramificação de tópico (geralmente em uma bifurcação do repositório, mas não necessariamente) e criar uma solicitação de recebimento entre essa ramificação e a ramificação "upstream". Nesse caso, o que está sendo revisado é um conjunto de confirmações que continua a crescer à medida que a revisão continua. O resultado é um conjunto de alterações que podem ser mescladas atomicamente quando concluídas. As solicitações pull podem ser eficazes no rastreamento de alterações com um escopo maior que pode ser implementado em várias confirmações. As solicitações pull também suportam fluxos de trabalho do SCM aos quais mais desenvolvedores estão acostumados, como responder a um comentário de revisão enviando uma confirmação de acompanhamento na mesma ramificação.

Uma grande vantagem a favor do Github é o número de desenvolvedores familiarizados com ele em comparação com o Gerrit. O Gerrit pode ser popular entre os usuários avançados do Git, mas o uso sem atrito requer conhecimento intermediário ou avançado do git e tolerância a uma curva de aprendizado acentuada.

A vantagem de Gerrit é um relacionamento mais profundo com o Git. As solicitações pull do Github estão suficientemente afastadas do modelo de dados padrão do Git para que seja necessário usar a UI da web do Github ou sua API proprietária para criar solicitações pull. A interface da Gerrit para criar e atualizar alterações é o próprio protocolo git.

— Martin Atkins
fonte

Obrigado Martin, é uma resposta interessante. Estou pensando em olhar para Gerrit por um tempo, mas acho que vou arquivar isso. Se isso encoraja o histórico de edições e confirmações de esmagamento, não quero nada com isso. * 8 '(

— Mark Booth

Apenas para esclarecer (eu uso o Gerrit frequentemente no meu local de trabalho), o que Martin diz aqui: "Gerrit ... incentiva os fluxos de trabalho do Git ... como alterar um commit anterior e pressioná-lo novamente ou esmagar um conjunto crescente de commits. ..em um único commit "está exatamente correto. Meu esclarecimento é que o comentário de @ MarkBooth sobre "histórico de edição" não é o que Martin disse. As confirmações de correção (enquanto ainda estão na Gerrit e ainda não foram mescladas à origem / mestre) não envolvem "histórico de edição". De fato, esse fluxo de trabalho funciona muito bem. A edição "ruim" da história a que Mark Booth se refere é re-empurrar as histórias editadas para a origem / mestre.

— likethesky

Obrigado pelo esclarecimento @likethesky, mas tenho uma interpretação mais literal do 'histórico de edição' e, no que me diz respeito, qualquer coisa que resulte em conjuntos de alterações que contenham conteúdo que você não confirmou explicitamente é 'histórico de edição'. Percebo, no entanto, que esta é uma interpretação bastante draconiana e uma que poucas outras aderem. * 8 ')

— Mark Booth

Justo. :-) Não sei se entendi o que você quer dizer com "conjuntos de alterações que contêm conteúdo que você não confirmou explicitamente", então pls. elaborado ... Suponho que você não esteja dizendo que nunca comete compromissos temporários (locais ou compartilhados entre os membros da equipe por meio de filiais remotas), como "WIP: isso tenta resolver o problema do arco que discutimos", seguido por um squash / correção mais útil que diz "Problema 123: XYZ refatorado para aumentar a resiliência e a facilidade de escala horizontal" como uma mensagem final de confirmação para esse trabalho. De qualquer forma, é claro que você pode optar por usar o git de qualquer maneira que o faça feliz!

— precisa saber é o seguinte

Esta é uma resposta fantástica. Para adicionar, descobri que as solicitações pull do GitHub promovem confirmações menores e mais iterativas e geralmente terminam com um log git muito mais descritivo que mostra não apenas o produto de trabalho, mas o processo de trabalho. A revisão de código da Gerrit promove um histórico de repositório muito mais limpo (existem muito, muito poucas confirmações de mesclagem reais) com confirmações maiores e mais polidas.

— tophyr