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

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).

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.

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.

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.