Digamos que estou escrevendo duas versões diferentes do mesmo software / programa / aplicativo / script e as armazenando sob controle de versão. A primeira versão é uma versão "Básica" gratuita, enquanto a segunda é uma versão "Premium" paga que pega a base de código da versão gratuita e a expande com alguns recursos de valor agregado extras. Quaisquer novos patches, correções ou recursos precisam encontrar o caminho para as duas versões.
Atualmente, estou pensando em usar master
e develop
branches para a principal base de código (versão gratuita) ao lado master-premium
e develop-premium
branches para a versão paga. Quando uma alteração é feita na versão gratuita e mesclada à master
ramificação (após testes completos develop
, é claro), ela é copiada para a develop-premium
ramificação por meio do cherry-pick
comando para mais testes e depois mesclada master-premium
.
Esse é o melhor fluxo de trabalho para lidar com essa situação? Existem problemas, advertências ou armadilhas em potencial a serem observados? Existe uma estratégia de ramificação melhor do que a que eu já criei?
Os seus comentários são extremamente apreciados!
PS Isto é para um script PHP armazenado no Git, mas as respostas devem se aplicar a qualquer idioma ou VCS.
fonte
Eu recomendo fortemente não usar ramos para esse fim. Em geral, você deve considerar ramificações para coisas que serão (ou poderão ser) mescladas novamente mais tarde (ou para ramificações de liberação, onde você eventualmente interromperá o desenvolvimento de uma das ramificações). No seu caso, você nunca mesclará suas versões "básica" e "premium" e elas serão mantidas indefinidamente, portanto, as ramificações não são apropriadas.
Em vez disso, mantenha uma versão comum do código-fonte e use a compilação condicional (por exemplo,
#ifdef
em C / C ++, não sei qual é o equivalente ao PHP) para incluir ou excluir as seções do código que diferem entre "básico" e "premium".Parece que o PHP pode não ter um recurso de compilação condicional embutido, então você pode usar o pré-processador C (
cpp
provavelmente já o possui) para pré-processar seu código-fonte comum e, a partir disso, produzir um "básico" e um "premium" versão sem as diretivas de pré-processador. Obviamente, se você optar por fazer isso, deverá usarmake
algo semelhante para automatizar o processo de execução do pré-processador.fonte
Estamos usando 2 projetos separados, o Básico e o Premium, que depende do projeto Básico. Não use braches, eles geralmente são usados para recursos.
fonte
Embora a maioria das respostas atuais seja a favor da compilação condicional em vez de ramificações, há um cenário em que há um benefício claro em usar ramificações: se você (agora ou mais tarde) decidir disponibilizar o código fonte da versão básica, incluindo todas as histórico de versões, mas excluindo todos os recursos premium, você pode fazer isso com a abordagem de ramificações, mas não com uma única ramificação e compilação condicional.
Aconselho não escolher a cereja e, em vez disso, mesclar todas as alterações da versão básica para a versão premium. Não deve haver recurso ou correção de bug incluída na versão básica, mas ausente na versão premium. Para tornar as coisas o mais simples possível, verifique se a ramificação premium modifica os arquivos comuns o menos possível. Portanto, a ramificação premium deve conter arquivos adicionais e talvez algumas pequenas modificações para criar instruções. Dessa forma, as alterações da versão básica serão mescladas automaticamente sem causar conflitos.
A resposta de Greg sugeriu que você “considere ramificações para coisas que serão (ou poderão ser) mescladas novamente mais tarde”. Com a abordagem que acabei de descrever este for o caso, a não ser que o ramo final para todos os commits será
master-premium
nãomaster
(que é, na verdademaster-basic
).Obviamente, os submódulos também seriam uma opção. Depende do seu processo de compilação, mas se você puder transformar a versão premium em um projeto que use a versão básica como um módulo, tudo bem. No entanto, você pode ter mais dificuldade se, em algum momento, decidir escolher recursos da filial premium para a filial básica. Com os submódulos, essa alteração seria representada como duas confirmações distintas, enquanto que com as ramificações, essa seria uma confirmação única para a versão básica, e a próxima mesclagem na versão premium saberia que essas alterações já estão incluídas e não têm para ser mesclado novamente.
fonte
No "hardware", isso é feito com frequência, são sistemas vendidos para controlar a bagunça, desculpe, não me lembro como eles são chamados.
Depois que a lavadora de roupas "de gama média" é enviada, seu código não muda senão para uma correção de bug muito importante, mesmo quando o mesmo código é alterado na lavadora de roupas "low-end" que é enviada alguns meses depois.
Os clientes não esperam receber atualizações para uma máquina de lavar roupa que já trouxeram; um novo modelo também não é enviado a cada poucos meses.
A maioria de nós não vive nesse mundo, o que Greg diz, a menos que você esteja escrevendo um software para máquinas de lavar.
fonte