O GitHub Flow é implantado na produção antes da mesclagem com o master: um segundo recurso não substituirá o primeiro?

8

No entendimento do GitHub Flow, como visto aqui , um recurso, após a revisão do código, é implantado primeiro na produção e depois mesclado no master.

Se houver um segundo recurso ramificado a partir do mesmo commit que o primeiro recurso, e esse também for implementado diretamente na produção, a produção não conterá mais o primeiro recurso.

feito em learngitbranching.js.org

Depois que o c2 é implantado, como o c3 pode ser implantado antes da fusão com o c2 ou c4?

Como o GitHub Flow lida com esse problema?

Uma solução óbvia seria exigir que um recurso fosse refeito no mestre antes de ser implementado na produção. No entanto, isso é propenso a erros humanos. Se alguém se esquece de se recuperar, a produção está perdendo um recurso.

Eu apreciaria especialmente as respostas daqueles que têm experiência com o GitHub Flow. Como você não tem esse problema?

git

— DarkSigma
fonte

1

Boas notícias! O GitHub tem um artigo sobre isso!

Eles identificam três medidas de segurança:

Certifique-se de que passa nos testes. Esperemos que isso faça parte da maioria dos fluxos de trabalho de implantação. Mas, é uma das medidas de "segurança" que eles enfatizam.
"Bloqueie" o pipeline de implantação conforme necessário: Quando uma ramificação de recurso está sendo implantada ou verificada na produção, ninguém mais pode iniciar uma implantação.
Verifique se todas as ramificações implantadas contêm todos os conjuntos de alterações já implantados. Como isso é feito é um pouco mais complicado. Aqui está o que eles dizem:

Usamos a API do GitHub para verificar esse requisito. Um terminal no aplicativo github.com expõe o SHA1 atualmente em execução na produção. Nós enviamos isso à API de comparação do GitHub para obter a "base de mesclagem", ou o ancestral comum, do mestre e do SHA1 de produção. Em seguida, podemos comparar isso com a filial que estamos tentando implantar para verificar se a filial foi capturada. Ao usar o ancestral comum de mestre e produção, o código que existe apenas em uma ramificação pode ser removido da produção e as alterações que chegaram ao mestre, mas ainda não foram implantadas, ainda não exigirão que as ramificações sejam mescladas antes da implantação.

Se a ramificação estiver atrasada, o mestre será mesclado automaticamente. Fazemos isso usando a nova ✨Merging API✨ que estamos disponibilizando hoje. Essa mesclagem inicia uma nova compilação de IC, como qualquer outro evento de estilo push, que inicia uma implantação quando passa.

A API de mesclagem basicamente executa uma mesclagem padrão - mas o faz no lado do servidor.

Sua solução provavelmente não precisa ser tão sofisticada. No final do dia, você só precisa de uma garantia razoável de que:

Os testes passam
Somente uma pessoa implanta por vez
O mestre é mesclado nas ramificações de recursos antes da implantação

— svidgen
fonte

Minha equipe decidiu fundir para dominar antes de implantar na produção. Nenhuma ramificação é mesclada no mestre, a menos que seja baseada no mestre. Após a mesclagem, todas as outras ramificações não mescladas (recursos ainda em andamento) devem ser restauradas para o mestre antes de serem elegíveis para revisão de código, teste (manual e com script) e eventual fusão no mestre. Quando um recurso está no mestre, é como se estivesse no prod, porque o mestre pode ser implantado a qualquer momento.

— DarkSigma

Parece uma péssima idéia implantar um aplicativo no Production que não tenha sido mesclado com a ramificação principal. Você pensaria que, se estiver movendo para Produção, você já testou a mudança em um ambiente de teste. Se ele falhar no Prod, basta reverter para a versão anterior. Tenho certeza que o Github tem suas razões, mas parece muito trabalho extra e pode levar a uma situação em que você não tem idéia do que realmente está em produção. Fusões ao mestre nem sempre vão bem se houver conflitos, para que pudesse ter o código em Prod que não corresponde ao que você pretende ...

— Erik Pearson

@ErikPearson Acho que a idéia é que você precisa pelo menos ter o mestre mesclado primeiro no ramo do recurso. Seu sistema de compilação não deve permitir a implantação de uma ramificação não imergível. ... Especular, é claro. Na verdade, não uso esse fluxo de trabalho. Mas, não me parece horrível com as ferramentas certas .

— svidgen

0

Esse problema já aconteceu com você ou é uma questão teórica?

O Git é "inteligente o suficiente" ao mesclar apenas o código alterado por push, se houver "problemas", isso causará um conflito de mesclagem.

Cada novo recurso é baseado na ramificação de desenvolvimento, e não os baseamos em outros recursos.

Uma coisa que fazemos para minimizar os conflitos de mesclagem é mesclar com frequência e, antes de iniciar um recurso, puxe sempre o desenvolvimento mais recente. (nunca nos comprometemos a dominar, mas sempre a um ramo de desenvolvimento, que será mesclado de vez em quando ao ramo mestre)

— Pieter B
fonte

2

Você não entendeu minha pergunta. Não se trata de conflitos de mesclagem e não há ramo de desenvolvimento. Eu pergunto sobre o fluxo do Git Hub (veja o link). Minha equipe deseja usar esse fluxo de trabalho, mas não entende por que implantaríamos um recurso não imerso. No entanto, isso parece ser uma inovação deste fluxo

— DarkSigma

Sempre há um ramo de desenvolvimento. Parece que você está chamando seu ramo de desenvolvimento de "mestre".

— Gnasher729 7/17