Como configurar uma revisão de código usando Gitlab?


86

Como configurar uma revisão de código usando Gitlab? Eu o vejo listado como um recurso no site do Gitlab, mas não consigo encontrar instruções sobre como configurá-lo (neste caso, qualquer link para um manual do usuário do Gitlab seria muito apreciado).

Algumas das minhas pesquisas indicaram que 'Solicitações de mesclagem' são o caminho a percorrer ... mas estou achando que são limitantes. Uma solicitação de mesclagem emitida mostra todos os commits entre um branch e outro. Parece que só consigo visualizar os diffs gerados para cada commit individual. Por exemplo, digamos que tenho um arquivo que desejo revisar. É um arquivo novo, mas enviei alterações nele em mais de 10 commits em um branch de desenvolvimento. Se eu emitir uma solicitação de mesclagem para esse branch dev da integração, vejo 10 commits em que cada um mostra as mudanças incrementais feitas no arquivo ... Quero revisar tudo. É novo!

Estou latindo na árvore errada aqui? Existe uma ferramenta real de revisão de código que eu possa usar no GitLab ou as solicitações de mesclagem são o caminho a percorrer e, se estiverem, estou usando-as incorretamente? qual é a melhor maneira de configurar uma revisão de código adequada aqui?


2
O GitLab 6.4 e sua visualização de comparação lado a lado podem ajudar na revisão do código: veja minha resposta abaixo
VonC

1
Com o GitLab 13.1 (junho de 2020), agora você tem Merge Request Reviews. Veja minha resposta editada abaixo
VonC

Respostas:


25

Observação: desde GitLab 6.4, a visualização de comparação lado a lado está disponível: consulte " solicitação de pull 5308 ".

(Julho de 2013)Ainda não há possibilidade de comentar em cada linha, apenas no nível do arquivo.
Daniel Sokolowski menciona nos comentários que os comentários por linha agora são suportados (09/2014):

Os membros da sua equipe podem comentar sobre a solicitação de mesclagem em geral ou em linhas específicas com comentários de linha.

Isso ainda pode ajudar na atividade de revisão de código.

https://f.cloud.github.com/assets/4224518/1558702/e0fe633a-4fa3-11e3-9388-3f3e445cb6d4.png


6 anos depois, para GitLab 13.1 (junho de 2020) :

As revisões de solicitação de mesclagem foram movidas para o núcleo

Introduzido originalmente no GitLab 11.4 como um recurso GitLab Premium, Merge Request Reviews permite que os revisores de solicitação de mesclagem:

  • envie vários comentários de uma vez,
  • reduzir o ruído de notificação para o autor da solicitação de mesclagem e
  • permitindo um processo de revisão mais coeso e simplificado.

https://about.gitlab.com/images/13_1/batch_comments.png

Desde sua introdução, reavaliamos seu lugar em nosso modelo de precificação com base no comprador e, como parte do 13.1, temos o prazer de anunciar que esse recurso mudou para o GitLab Core.

Veja a documentação e o problema


Comentários por linha agora são suportados: "Os membros de sua equipe podem comentar sobre a solicitação de mesclagem em geral ou em linhas específicas com comentários de linha." ( about.gitlab.com/2014/09/29/gitlab-flow )
Daniel Sokolowski

1
@DanielSokolowski Ótimo! Eu incluí seu comentário na resposta para mais visibilidade.
VonC

9

Tenho feito revisões de código no Gitlab por mais de dois meses quase sem atrito. Eu configurei o rss2email para enviar notificações por e-mail toda vez que um desenvolvedor envia novos commits. Então eu uso o recurso de comentário do Gitlab para commits para fazer alguns comentários sobre o código enviado.

Infelizmente, o Gitlab não permite comentários nos arquivos em si, apenas em commits (assim como o Github, eu acho). Sempre que me encontro em uma situação em que preciso comentar algo que perdi em um commit anterior, uso a ferramenta de culpa para encontrar o commit que introduziu / alterou a seção de código a ser comentada.

Está longe de ser perfeito, mas está funcionando bem até agora.


1
Em vez de rss2email, pode-se usar notificações Gitlab para ser notificado sobre pushes.
vadipp

Eu tenho o mesmo problema / solução alternativa. Eu acredito que seria uma boa adição de recurso que você pudesse adicionar um comentário ao commit correto culpando uma linha específica no diff ou na visualização de arquivos (quero dizer, a partir da interface da web navegando em arquivos ou diffs, não executando a culpa).
AlejandroVD

2

Você pode ver o código enviado em Merge Request para outro repositório ou no repositório atual.
exemplo http://demo.gitlab.com/diaspora/diaspora/commits/master

Então você pode adicionar comentários às alterações do arquivo submetido (botão Reply) ou a todo o commit

exemplo http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

A comunicação resultante é a revisão do código . No entanto, eu pessoalmente recomendo fazer a revisão do código em um PC com comunicação face a face sempre que possível e usar ferramentas para registrar os resultados ou quando mais formalidade for necessária.

Para um arquivo de revisão que tem muitos commits, por exemplo, http://demo.gitlab.com/diaspora/diaspora/blame/master/README.md olhe para ele usando blamepara entender quem fez o quê. No entanto, nesta visualização, não há opção de comunicar e adicionar comentários. Eu recomendaria apenas adicionar alterações como comentários neste caso.


7
Recebo um 404 para o primeiro, segundo e último link em sua resposta.
Bryan Oakley

1
Como diz na página inicial, demo.gitlab.com "É UMA CAIXA DE SANDBOX - ela é reiniciada a cada hora", então todos os exemplos foram apagados. Este não é um bom veículo para exemplos.
Uriah Blatherwick de

Sim, por favor, reconsidere configurá-lo com exemplos adequados. Em geral, sua resposta parece ser um conselho sólido.
dados de

0

Sim. Solicitações de mesclagem são como as revisões de pares são realizadas.

Deve haver uma guia 'diff' que mostrará as alterações de todos os commits (mencionados aqui: http://youtu.be/DyAX8ws5OIc?t=3m2s ).

O vídeo também explica como pode ser usado para revisão por pares.


0

O caso de uso normal de revisões de código é revisar o código em um branch antes de fundir no master ou similar. Eu tenho uma situação em que desenvolvi um projeto e quero que todo o código seja revisado por todos da equipe.

O que eu fiz foi:

Verifique o primeiro commit, faça uma mudança nele, faça um commit e push

git co -b FIRST_COMMIT eb67f06c2b3222c0219214b176c41922bc454881
vi README.md
git add README.md
git ci -m "First commit modified so can get full diff against it"
git push --set-upstream origin FIRST-COMMIT

Verifique o último commit, faça uma mudança nele, faça um commit e push

git co -b master
vi README.md
git add README.md
git ci -m "Last commit modified so can get full diff against it"
git push --set-upstream origin LAST-COMMIT

No GitLab / GitHub, crie uma solicitação pull

  • É uma fusão de LAST_COMMIT com FIRST_COMMIT

Funciona para mim!


Isso não deixa você com dois branches "lixo" no repositório e nenhum rastreamento dos comentários no branch master? Se os comentários exigirem alterações no código, você então os mescla para o mestre?
user2084572

Sim, haverá ramos FIRST_COMMIT e LAST_COMMIT que são fáceis de excluir ( git br --delete --force origin FIRST_COMMIT LAST_COMMIT; git br --delete --force FIRST_COMMIT LAST_COMMIT). Você pode usar um branch off master diferente para conter as alterações ou criar problemas separados manualmente. E depois crie um ou mais branches (por exemplo, um por problema) se houver muito feedback.
HankCa
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.