Git-flow e master com vários release-branches paralelos

86

Estamos tentando adotar o modelo de ramificação Git implementado pelo git-flow. Agora, estamos trabalhando em pelo menos dois ramos de lançamento, um para o lançamento estável mais recente e um para o próximo lançamento ("visualização"). O que não entendo é porque todos os lançamentos parecem "linearizados" para o mestre e marcados lá. Por que não marcar os lançamentos em seus ramos de lançamento? Por que o mestre afinal? Ou por que desenvolver um branch e não usar o master para ele?

Mot
fonte

Respostas:

77

No modelo git-flow, sua versão "lançada mais recentemente" mapeia para o master, enquanto sua "versão de visualização" mapeia para um releasebranch git-flow . Ele é bifurcado develope finalmente mesclado masterquando ocorre a liberação real. Então, esta se tornará sua "versão mais recente" e você normalmente corrigirá apenas os bugs dessa versão, usando hotfixramos do git-flow . Desta forma, você mastersempre representa o estado mais estável de sua última versão lançada.

Se você quiser consertar bugs de lançamentos mais antigos ou desenvolver qualquer outro ali, você fará um fork de um supportbranch do commit apropriado master(você terá todas as versões criadas lá). supportramos ainda são experimentais (de acordo com os documentos ) e não estão bem documentados. Mas como você pode ver na ajuda da linha de comando:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

essas ramificações acabaram de ser iniciadas e não se destinam a ser mescladas de volta a masternor develop. Isso geralmente é bom, pois as correções para versões "antigas" ou recursos solicitados pelos clientes para serem implementadas em versões "antigas" não podem ou não devem voltar master. Se você ainda pensa que deseja portar uma correção para sua linha de desenvolvimento principal (representada por mastere develop), basta iniciar um hotfix, selecionar suas alterações e terminar o hotfix.

mstrap
fonte
17
Isso não lida com um pipeline lento do teste ao controle de qualidade e à produção. Pode haver dois (ou até mais, mas digamos apenas dois por enquanto) ramos de lançamento abertos, cada um em um estágio diferente do pipeline e cada um necessário para permitir correções para bugs encontrados no teste. O branch de desenvolvimento seria, então, onde os recursos estavam sendo acumulados para uma versão cujo branch ainda não foi feito. Em tal situação, uma correção no lançamento n-2 seria eventualmente mesclada para desenvolver, mas pularia o lançamento n-1, pelo menos seguindo o fluxo padrão do git. Isso levaria a uma regressão em n-1, eventualmente corrigida na versão n
Brendan
Por que os ramos de lançamento não seriam mantidos e, uma vez que o ramo de lançamento mais novo é criado, os mais antigos evoluem para um ramo de "suporte"?
lkanab
1
Por que os ramos de lançamento são "bifurcados" do desenvolvimento e não apenas "ramificados" do desenvolvimento?
Sandra K
gitflow-avh parece um fork mantido (isto é, não morto) do gitflow original. git flow supportnão está marcado como experimental.
Timo Verhoeven
9

Parece mais um modelo mental com ênfase um pouco demais nos ramos. Eu concordo, você poderia apenas marcar os commits que liberar em vez de mesclá-los de volta ao master.

A imagem é bonita, no entanto. Mesclar tudo de volta no mestre dá uma indicação clara dos lançamentos em ordem temporal, em vez de ter tags de versão espalhadas por todo o gráfico.

Eu acho que este modelo não funciona para correção de bugs em versões mais antigas. Isso atrapalha a ordenação organizada.

  1. Digamos que lançamos a versão 1.0.1 e mais recursos adicionados e lançamos 1.1.0.
  2. Descobrimos um bug em 1.0.1 e queremos corrigi-lo em ambas as versões
  3. Temos que adicionar 1.0.2 após 1.1.0 no mestre e, em seguida, atribuir diretamente (ou antes) também 1.1.1.

Para responder à sua pergunta: eu acho que este é um conjunto de regras que constitui um modelo mental simples em alguns casos. Nem todas as regras fazem sentido do ponto de vista puramente técnico, mas isso não as torna ruins. Os modelos mentais são bons para eles humanos.

Sarien
fonte
1
supportbranches são projetados para correção de bugs em versões mais antigas, embora ainda rotulados como 'experimental'.
mstrap
2

Eu pessoalmente acho que o fluxo do git mencionado é complicado demais.

Se você estiver usando o GitHub, tente o GitHub flow(conforme descrito por Scott Chacon).

É especialmente útil para colaboração em vários recursos, revisão de código e você pode combiná-lo com sua solução de Integração Contínua usando o Commit Status API.

ATUALIZAÇÃO : há um novo site oficial do GitHub Flow ™

ATUALIZAÇÃO 2 : há um novo guia oficial (e simplificado) do GitHub para o GitHub Flow ™: https://guides.github.com/introduction/flow/

Haralan Dobrev
fonte
10
O fluxo do GitHub é adequado apenas para um contexto não centrado no lançamento: O processo git-flow é projetado principalmente em torno do "lançamento". Na verdade, não temos "lançamentos" porque implantamos na produção todos os dias - muitas vezes várias vezes ao dia.
Remi Mélisson
10
Eu também acrescentaria que o git-flow não funciona muito bem em um contexto centrado no lançamento que possui lançamentos de manutenção. Por exemplo, o que acontece quando uma versão 1.2.1 ocorre após uma versão 1.3.0? Provavelmente não pode ser mesclado com master, uma anomalia da cronologia do trabalho.
Ken Williams
@KenWilliams conforme descrito na resposta do mstrap , é para isso que supportservem os branches. Mas você está certo, é realmente uma anomalia que essas versões não sejam mescladas de volta master, o que - no meu entendimento - deve conter todas as versões de produção.
beatngu13
2

No meu caso, tenho duas versões do mesmo software cujos princípios básicos são os mesmos, mas cada versão possui alguns recursos diferentes.

Então, eu crio dois worktreeque significa criar dois branches relevantes de longa duração ao lado do mestre.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Então eu tenho:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

Existe um repositório, mas tenho 3 pastas separadas uma ao lado da outra para cada branch acima. E faça as mudanças comuns no mestre. em seguida, mescle-o com as outras versões.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Mudanças específicas de cada versão irão para a pasta correspondente também, e os trabalhos em cada projeto são isolados e o IDE não seria confundido.

Espero que ajude.

Vaheeds
fonte
2

Concordo totalmente com @Mot.

É bom ouvir as mesmas perguntas.

Nossa equipe também foi procurada por mais modelos de ramificação universal do que de sucesso . Ou seja, como @Mot mencionado acima - a idéia principal é evitar a introdução de repositórios extras para suportar ramos release- * em repositório * .git separado, pois isso é feito, por exemplo, por kernel.org para lançamentos estáveis. Mas kernel.org faz isso para minimizar os tamanhos baixados, eu acho.

Para mim, parece que é mais limpo ter o master como linha principal para desenvolver .

Além disso, existem alguns conflitos no lançamento- * modelo de mesclagem para masterizar e marcá-lo posteriormente com a ideia

usar um script de gancho Git para construir e distribuir automaticamente nosso software para nossos servidores de produção sempre que houver um commit no master

porque o acabamento (mesclagem e marcação) não é uma transação atômica:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

e se o git hook começar a compilar com suporte de versão automática:

$git describe --tags --long >.ver

então uma versão errada pode ser construída para:

$ git merge --no-ff release-1.2

Eu sei que o controle de versão em Bem - sucedido introduz algum processo de versão bump, mas não é automático.

Então, para resumir - as principais diferenças que introduzimos no modelo de branch para lançamentos- * mesclagem e marcação são: - marcar o lançamento ao criar seu branch - manter o branch do lançamento para permitir sua manutenção no futuro

mdn
fonte
-2

O branch master deve SEMPRE representar sua base de código de produção, portanto, você sempre mescla o código de volta ao master logo após um lançamento de produção.

A marcação é usada para "memorizar" o código exato que entrou em uma versão de produção para que você possa voltar mais tarde e analisar o código se algo der errado.

Com isso, teoricamente, não deveria importar se você etiquetar seu código no branch de lançamento ou no branch master depois de fundir de volta ao master. Eu pessoalmente prefiro marcar o código no branch de lançamento, pois este é exatamente o código que foi incluído na construção / lançamento (assumindo que algo pode dar errado com a fusão).

O problema com o conceito de ramo de desenvolvimento é que ele é de segmento único. Brendan neste tópico mencionou uma estratégia que poderia ser usada envolvendo um conceito de ramo de desenvolvimento.

Bernie Lenz
fonte
4
O que é uma "base de código de produção" se você mantém várias versões, por exemplo, v1.0, v1.1, v1.5 em paralelo?
Thomas S.
Base de código de produção é o que está em produção agora, por exemplo, v1.0. As ramificações trazem alterações para versões a serem implantadas na produção no futuro, por exemplo, V1.0.1, v1.1 e v2.0. Depois que uma versão "futura" é implantada na produção, ela é mesclada de volta ao mestre, de forma que o mestre reflita o que está em produção. Ele também é mesclado (por exemplo, v1.0.1 para 1.1 e v2.0) para que as alterações da v1.0.1 não sejam perdidas quando a v1.1 for lançada para produção.
Bernie Lenz
4
Estou falando sobre manter várias versões lançadas, não sobre versões futuras.
Thomas S.
4
Você parece não me entender. Você não consegue imaginar que em algumas empresas várias versões de lançamento são mantidas? A Microsoft, por exemplo, também mantém atualizações para Windows 7, 8, 8.1 e 10, então por que não outras empresas?
Thomas S.
1
Isso é correto Thomas. Este modelo é voltado para produtos que possuem uma única versão de produção em um determinado momento, como, por exemplo, sites da web. Também usei esse modelo para compilações móveis, por exemplo, Android e iPhone, onde a compilação é parametrizada para produzir uma compilação de Android ou iPhone (ou ambos) usando o mesmo número de versão. Estou curioso para saber sua opinião sobre como estruturar um modelo de compilação para um produto que possui várias versões ativas em produção em um determinado momento, possivelmente com alguns componentes compartilhados e alguns componentes diferentes. Informe-nos ...
Bernie Lenz