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

Com o git e o github regulares, eu posso fazer uma revisão de código simplesmente criando uma solicitação de recebimento do ramo de recursos em que estou trabalhando no ramo mestre. Como eu faria revisões de código com o git-flow? Com o fluxo de trabalho como "git flow feature finish", estou confuso sobre o local onde a revisão do código realmente acontece e como o git-flow ou o git pode facilitar essa revisão.

Nos deparamos com esse problema exato recentemente. Nós realmente gostamos do fluxo git, pois ele usa um bom nível de semântica (usando o mesmo nível usado na discussão em equipe: "Vou iniciar o recurso A" mais do que "vou criar um ramo, fazer checkout"), enquanto O git é um nível muito "de implementação" (que também é bom e útil, mas diferente).

O problema que temos é git feature finisho de mesclar a ramificação ao desenvolvimento, enquanto queremos que uma solicitação de recebimento seja enviada e (isso é importante) mesclada pelo revisor , e não pelo responsável, para enfatizar a propriedade da equipe.

Nossa solução atual:

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

Isso é consistente com a nossa prática, com a desvantagem de exigir a exclusão do ramo por conta própria (como não damos acabamento ao fluxo). Nosso próximo passo provavelmente será reimplementar algumas partes do fluxo git (como se trata principalmente de encadear comandos git) para levar isso em consideração (tendo a parte "limpeza" do acabamento, sem a mesclagem).

O processo que a equipe com a qual trabalho usa é o seguinte:

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

Normalmente, todo esse processo é realizado pelo autor original, mas isso não é necessário. Qualquer pessoa da nossa equipe pode intervir e iniciar esse processo a qualquer momento. Tudo o que eles precisam fazer é verificar o ramo de recursos e continuar o processo. Quem já executou git flow feature finish module_1terá o luxo de excluir seu ramo de recurso local, mas qualquer pessoa que faça check-out do ramo precisará fazer isso manualmente, se quiser usar algo parecido git branch -D feature/module_1.

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

Se você estiver revisando códigos, presumirei que você tenha um repositório central que contém o código "oficial". Os desenvolvedores extraem e enviam para este repositório central.

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

1. O desenvolvedor faz alterações em qualquer filial, confirma localmente.
2. O desenvolvedor envia essas alterações para a Gerrit.
3. A Gerrit cria itens de revisão para outros revisarem.
4. Os pares revisam o código, fazendo comentários e aceitando ou rejeitando o commit.
5. Quando a cometer for aceite, então Gerrit introduz as alterações disponíveis para os outros para puxar a partir do ramo.

Ao usar um repositório central, outros desenvolvedores podem ver as alterações enviadas após a etapa 2. Gerrit apresenta o fluxo de trabalho de revisão de código e, portanto, outros desenvolvedores apenas veem 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 das alterações feitas em qualquer ramificação.

Aqui está outra sugestão.

1. Execute o processo regular de fluxo git para criar um recurso , mas não o termine ou mescle.
2. Crie uma solicitação de recebimento , mas não a mescle. Aguarde o aprovador deixar um comentário. O comentário é a marca da aprovação.
3. Faça o fluxo git terminar . (O aprovador ou o desenvolvedor pode fazer isso, dependendo do que a equipe concordou.) A solicitação de recebimento será marcada como mesclada no github. Você ainda precisa excluir a ramificação na origem.