revisão de código com git-flow e github

39

Com o git e o github regulares, posso fazer uma revisão de código simplesmente criando uma solicitação pull do branch de recursos em que estou trabalhando para o branch master. Como eu faria revisões de código com o git-flow? Com o fluxo de trabalho como "acabamento do recurso de fluxo git", estou confuso sobre onde a revisão de código realmente acontece e como o git-flow ou git pode facilitar essa revisão.

    
por AdamT 20.02.2013 / 15:01
fonte

4 respostas

28

Nós topamos com esse problema exato recentemente. Nós realmente gostamos do fluxo do git, pois ele usa um bom nível de semântica (usando o mesmo nível que você usa na discussão em equipe: "Eu começarei o recurso A" mais do que "eu vou criar um branch, check-out"), enquanto git é um nível muito "de implementação" (que é bom e útil também, mas diferente).

O problema que temos é com git feature finish , pois ele mescla o branch no develop, enquanto nós queremos que um pull request seja enviado e (isso é importante) mesclado pelo revisor , não o committer, para enfatizar a propriedade da equipe.

Nossa solução atual:

  1. Alguém usa o fluxo do git para criar um ramo de recurso
  2. Quando terminar, ele cria uma solicitação pull (usando o github)
  3. A revisão ocorre, com potenciais confirmações adicionais
  4. A solicitação pull é mesclada usando o GitHub pelo revisor .
  5. Não há conclusão do recurso de fluxo do git (como a filial já está mesclada)

Isso é consistente com nossa prática, com a desvantagem de precisar excluir a ramificação por nós mesmos (já que não concluímos o fluxo). Nosso próximo passo provavelmente será reimplementar algumas partes do fluxo git (como é principalmente sobre encadear comandos git) para levar isso em conta (tendo a parte de "limpeza" do acabamento, sem a mesclagem).

    
por 03.03.2013 / 11:44
fonte
15

O processo em que a equipe com quem trabalho usa isso é o seguinte:

  1. Crie uma ramificação de recurso: git flow feature start module_1
  2. O código é atualizado no ramo de recursos
  3. À medida que as alterações são confirmadas, elas são enviadas ao GitHub (ou uma vez no final, se preferir)
  4. Quando o recurso for concluído, uma solicitação pull será aberta no GitHub, comparando develop e a ramificação de recurso module_1
  5. A equipe analisa a solicitação de recebimento e faz comentários
  6. Quaisquer alterações da solicitação de recebimento são feitas no ramo de recursos
  7. Depois que todas as alterações forem incorporadas na ramificação do recurso, a ramificação do recurso será concluída: git flow feature finish module_1
  8. A ramificação develop é enviada ao GitHub (o GitHub marcará automaticamente a solicitação pull como fechada / mesclada quando isso acontecer)

Normalmente, todo esse processo é feito pelo autor original, mas isso não é obrigatório. Qualquer um em nossa equipe pode entrar e pegar esse processo a qualquer momento. Tudo o que eles precisam fazer é verificar o ramo de recursos e continuar com o processo. Quem já executar git flow feature finish module_1 terá o luxo de sua ramificação de recurso local ser excluída, mas qualquer outra pessoa que tenha feito check-out da filial precisará fazer isso manualmente se quiser usar algo como git branch -D feature/module_1 .

Para os hotfixes, usamos uma abordagem semelhante e criamos a solicitação pull no GitHub antes de terminar o hotfix.

    
por 24.10.2013 / 23:52
fonte
3

Se você estiver fazendo revisões de código, presumo que você tenha um repositório central que contenha o código "oficial". Desenvolvedores puxam e empurram para este repositório central.

Quando você usa o Gerrit , o próprio Gerrit se torna o repositório central (ele tem servidores SSH e HTTP integrados que permitir que os usuários interajam com ele basicamente da mesma maneira que eles já são). Ao usar o Gerrit, o fluxo de trabalho se torna:

  1. O desenvolvedor faz alterações em qualquer filial, comete localmente.
  2. O desenvolvedor envia essas alterações para o Gerrit.
  3. Gerrit cria itens de revisão para outras pessoas revisarem.
  4. Os colegas revisam o código, fazem comentários e aceitam ou rejeitam o commit.
  5. Quando o commit é aceito, então o Gerrit disponibiliza as alterações para que outras pessoas saiam do branch.

Ao usar um repositório central, outros desenvolvedores podem ver as alterações enviadas após a etapa 2. O Gerrit apresenta o fluxo de trabalho de revisão de código e, assim, outros desenvolvedores só verão as alterações enviadas após a etapa 5.

Isso funciona bem com o git-flow (ou qualquer outro esquema de ramificação) porque o Gerrit suporta a revisão de alterações feitas em qualquer ramificação.

    
por 20.02.2013 / 21:54
fonte
2

Aqui está outra sugestão.

  1. Faça o processo de fluxo regular do git para criar um recurso , mas não termine ou mescle-o.
  2. Crie uma solicitação pull , mas não a mescle. Aguarde o aprovador deixar um comentário. O comentário é a marca de aprovação.
  3. Faça o acabamento do fluxo do git . (O aprovador ou o desenvolvedor podem fazer isso, dependendo do que a equipe concordou.) A solicitação pull será marcada como mesclada no github. Você ainda precisa excluir a ramificação na origem.
por 07.01.2016 / 15:26
fonte