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?
Respostas:
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.
git flow supportnão está marcado como experimental.
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.
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.
supportbranches são projetados para correção de bugs em versões mais antigas, embora ainda rotulados como 'experimental'.
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/
master, uma anomalia da cronologia do trabalho.
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.
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.
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
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.