Gerrit: Trabalhando com várias filiais e propagação de mudanças

Question

Estou tentando identificar a maneira correta de trabalhar com vários ramos na Gerrit que corresponderia ao nosso fluxo de trabalho.

A maneira como trabalhamos com galhos agora é: nós temos ramo de mestre e recurso. Mestre é o ramo que queremos polir e torná-lo pronto para lançamento, enquanto o recurso é obviamente um campo de trabalho intensivo. Agora, em nosso caso particular, sempre que alguém trabalha em uma correção de bugs, eles:

• Crie uma alteração direcionada para o ramo principal
• Cherry pegá-lo para a mudança de recurso Alvo alvo
• Uma vez que a revisão do código Gerrit seja concluída, envie as duas alterações.

Agora a maneira como eu entendo Cherry-Pick, seleciona cometimento individual e mescla para a mudança atual. Se for esse o caso, eu esperaria não ter conflitos de mesclagem no final e, de fato, este fluxo de trabalho funciona perfeitamente com apenas Git. Gerrit, no entanto, provavelmente devido à sua natureza (filiais não são mescladas remotamente a maneira como estas são localmente e obter uma tag SHA diferente) listas um tremendo número de arquivos conflitantes no final.

Agora, resolvi todos esses problemas aplicando estratégia de mesclagem (o nosso recurso, deles no mestre), mas não se sente certo: se alguma coisa não fosse propagada, apenas foi descartada.

minha pergunta é: existe um fluxo de trabalho seguro , semelhante ao acima, que no final produziria uma mesclagem limpa com Gerrit?

Answer 1

Eu diria que é melhor, neste caso, para se fundir do que a escolha de cereja.

Uma escolha de cereja adiciona as mesmas alterações mas não o mesmo commit . Então, enquanto a fonte é a mesma em uma escolha de cereja e mesclar a árvore git é diferente. Quando a árvore é diferente e você mais tarde faz uma mágica vai pensar que o commit você previamente Cherry escolheu está faltando e tenta mesclar essa mudança também, mesmo que o código real já esteja lá. Isso é provavelmente por isso que você recebe muitos conflitos.

Eu proporia outra maneira de trabalhar.

• Quando você faz o trabalho normal que você desenvolve no recurso e empurre para Gerrit normalmente.
• quando você faz um patch (ou seja, bug corrigir) no ambiente de produção estável você faz isso diretamente em mestre (ou ramos locais, se você gosta, mas não em )
• Quando o patch foi aprovado em Gerrit, fica fundido no Real Master e você pode fazer uma solicitação de tração para obter essa mudança para sua cópia local. Sua versão mestre é agora o mesmo que Gerrits mestre
• Agora você mesclaria todas as novas alterações em mestre em recurso . Certifique-se de fazer um rebase para que o patch acaba antes de qualquer coisa que você já tenha feito em recurso
• Uma vez que é hora de implantar todos os novos recursos, você pode mesclar recurso em mestre , empurrar para Gerrit (se você tiver permissões, você pode passar pela passagem diretamente para < forte> mestre em vez de refs / para / mestre como essas alterações já são revisadas)
• Uma vez que todas as alterações estiverem em Gerrits mestre você faz um puxão no seu mestre e uma mesclagem em recurso com rebase Fazendo Recurso Um ramo limpo para trabalhar. É claro que é totalmente válido ter um novo recurso cada lançamento. Ambos funcionam bem.

Answer 2

Estou um pouco confuso, já que este fluxo deve funcionar bem.Se outros usuários enviarem alterações antes que sua correção de bugs seja revisada / verificada / enviada, isso pode resultar em conflitos de mesclagem, mas isso deve ser raro.

Se você:

.
1. consertar um bug no mestre
2. empurrar para rever (criar mudança A em Gerrit)
3. Cherry-Pick altera um no topo da filial de recurso (resolvendo quaisquer conflitos do mestre para recurso)
4. empurre a mudança colhida de cereja para rever (criar alteração b)
5. revisão / verifique / enviar alterações a & b

Tudo vai funcionar bem.A única maneira de mesclar conflitos ocorrer é se outros usuários upload e enviar alterações entre as etapas 1 e 5. Você está vendo um comportamento diferente?Você pode fornecer mais detalhes?