Qual é o melhor processo para revisão de código ao usar o GIT? Temos um provedor GIT externo (Unfuddle) e temos limites no uso de recursos – portanto, não podemos ter repositórios remotos dedicados para cada desenvolvedor.
Processo atual:
- Nós ter um servidor GIT com um
masterbranch para o qual todos se comprometem - Devs trabalham fora do espelho
masterlocal ou um branch de recurso local - Devs push para servidor “s
masterbranch - Devs request code review on last commit
Problema:
- Qualquer bug na revisão de código já está no controle no momento em que é detectado.
- Pior, geralmente alguém gastou algumas horas tentando para descobrir o que aconteceu …
Então, gostaríamos
- de fazer a revisão do código ANTES da entrega no “mestre”.
- Ter um processo que funcione com uma equipe global (nada de revisões por cima do ombro !)
- algo que não exija que um desenvolvedor individual esteja em sua mesa / máquina ser ligado para que outra pessoa possa controlar i n (remova a dependência humana, os desenvolvedores vão para casa em fusos horários diferentes)
Usamos o TortoiseGIT para uma representação visual de uma lista de arquivos alterados, dife “rando arquivos etc. Alguns de nós caem em um Shell GIT quando a GUI não é suficiente, mas idealmente gostaríamos que o fluxo de trabalho fosse simples e baseado na GUI (quero que a ferramenta elimine qualquer fardo, não meus desenvolvedores).
Comentários
- Você está fazendo um teste de unidade antes de se comprometer?
- @GuyCoder: Geralmente, fazemos.
- Se o seu host não fornece revisão de código capacidade, obtenha um host melhor. Dê uma olhada no Gerrit e veja se você pode encontrar um host que o forneça.
Resposta
A O modelo simples, mas eficaz, é o modelo GitHub pull request , em que os contribuidores arquivam as solicitações “por favor, mescle no meu código”. Um mantenedor revisa os changesets e decide se eles precisam de mais trabalho ou se são adequados para fusão. Ele então pode se fundir no branch master. Em geral, os committers não podem ser enviados diretamente para o branch master (isso pode ser personalizado de acordo com seus gostos, permitimos que commits “menores” entrem diretamente).
Comentários
- Temos uma equipe compacta de 7 desenvolvedores profissionais (versus colaboradores anônimos) em todo o mundo, então é seguro deixar cada um enviar diretamente para o nosso mestre remoto. Embora ' seja um link + introdução vs respostas autônomas que eu prefiro, neste caso faz sentido. Ótimo artigo no link, obrigado!
- @Sid Com uma equipe de 3 eu não ' deixaria todos eles empurrarem para o mestre.
- As solicitações pull também estão disponíveis em Rhodecode e Atlassian Stash
- @Andrew: Por que não? Muitos problemas podem ser gerados canalizando todo o trabalho da equipe através de um ponto de estrangulamento. Tudo isso pode ser atenuado, mas um comando de ponto único e estrutura de controle são mais adequados para algumas situações do que outras.
Resposta
Git é um sistema de controle de versão distribuído: não tenha apenas um repo com um branch!
Você pode configurar vários repositórios – um para cada desenvolvedor – e outro que é o repo master. Quando um de seus ramos está pronto para ser mesclado, o desenvolvedor solicita uma mesclagem e suas alterações são puxadas de seu ramo / repositório para o mestre.
Antes que a mesclagem realmente aconteça, o revisor pode puxar as mudanças para seu ambiente e revise-os antes de forçá-los a masterizar.
As vantagens adicionais são que, dessa forma, um desenvolvedor pode ter quantos branches quiser, com o nome que quiser, sem interferir um no outro ou mesmo ter para ver a roupa suja uns dos outros.
Além disso, aprenda o jargão: por “Devs comprometer-se com o branch master do servidor” você quer dizer que eles enviar suas alterações para mestre?
Comentários
- sim, eles
pushtrabalho deles. Não podemos ' ter repositórios remotos exclusivos no servidor GIT porque pagamos um hoster GIT e eles cobram por repositório. Você quis dizer ter vários branches remotos por desenvolvedor? E quando você dizthe reviewer can pull the changes into their environmentque comandos GIT exatos (ou fluxo do TortoiseGIT) você quer dizer? - Não, quero dizer ter vários repositórios; um por desenvolvedor, e nesse repositório eles podem ter quantas ramificações quiserem. Quanto a
pull, eu não ' não sei qual seria o comando em TortoiseGIT – mas o comando é git pull . É ' é o oposto de um push – você puxa as alterações do repositório remoto para atualizar seu ambiente com o trabalho que outros desenvolvedores podem ter feito. - Eu sei
git pull🙂 …Eu estava pedindo a sintaxe completa para inspecionar o sistema repo / branch / tag para push / pulls que você estava se referindo. No momento, fazemosgit pullde qualquer maneira, ' está apenas fora de remote: master – o que causa os problemas. De qualquer forma, os links de Steven ' s foram ótimos. Obrigado - Para todos os fins práticos, neste caso, um branch no repo hospedado é exatamente o mesmo que outro repo.