É uma boa prática usar ramificações para manter diferentes edições do mesmo software?

Isso depende da magnitude da mudança, mas eu não consideraria isso uma boa prática para as diferenças que você descreveu.

Geralmente, você quer que uma ramificação do Git seja algo que será mesclado no futuro ou armazenado como somente leitura para referência. As ramificações do git que coexistem indefinidamente significam trabalho para todos: as mudanças precisam ser propagadas e mescladas, os conflitos resolvidos, toda a diversão. Se nada mais, todo desenvolvedor tem que lembrar de enviar mudanças para cinco repositórios ao invés de um.

Se você tiver pequenas alterações, todo o esforço de mesclagem e manutenção de filiais parecerá excessivo quando comparado ao problema. Use seu pré-processador ou sistema de construção para diferenciar as versões. Um simples #ifdef faz o truque? Então não resolva problemas com o git, é exagero.

Não é para isso que servem os ramos. As ramificações devem ser caminhos secundários de curto a médio prazo para sua linha de desenvolvimento, e não versões paralelas de longo prazo do mesmo código.

Eu colocaria todas as versões diferentes no mesmo branch, com subdiretórios para as partes que são diferentes entre as edições, e configuraria o seu processo de compilação (você tem uma compilação automatizada, certo?) para que possa gerar edição on demand (ou todas elas ao mesmo tempo).

Afinal, você quer manter uma "única fonte de verdade"; com ramificações, você estará duplicando alguns códigos, mas não todos, e certas mesclagens de fato quebrariam sua configuração.

Uma solução - como as pessoas apontaram - é configurar o sistema de construção para suportar diferentes edições.

Também consideraria implementá-lo como recurso alternar e usar um arquivo de configuração. Quanto menos você tiver que construir, melhor.

Dê uma olhada neste site.

Eu acho que é uma boa ideia, desde que você não possa fazer isso em uma ramificação sem agrupar muito o código.
Eu preferiria poder mantê-lo em uma ramificação e usar arquivos localizados e de configuração, especialmente se você disser que as diferenças são pequenas.
Outra maneira poderia ser construções diferentes, por exemplo, seu arquivo de construção embala arquivos diferentes para clientes diferentes, mas também posso ver a ferramenta de construção verificando diferentes ramificações. Como você usa o git eu diria que não há dicas reais. Uma estratégia de ramificação poderia ser desenvolver em diferentes ramificações para diferentes tarefas, fazer check-in no branch master e mesclar do master para editionX e Y.

Isso soa mais como um trabalho para diferentes configurações de criação. A resposta de thiton vai nessa direção, mas eu levaria isso muito além de #ifdef :

Use destinos de compilação diferentes para criar diferentes edições do software. Os alvos podem diferir por

• a configuração que eles incluem,
• o objeto ou arquivos de origem que eles incluem ou
• o pré-processamento do código-fonte.

Este pré-processamento pode obviamente incluir o pré-processador C clássico, mas também pode implicar o uso de um pré-processador personalizado, um mecanismo de template para construir views customizadas,…

Dessa forma, você evita ter de pressionar ativamente cada alteração em várias ramificações, o que viola o DRY (é claro que isso também pode ser automatizado, mas não vejo a vantagem).

Eu usaria ramificações somente para mudanças significativas, senão você acabaria adicionando cada pequena alteração a várias ramificações, o que não é nada divertido de se fazer e é muito propenso a erros, especialmente se você estiver trabalhando com mais pessoas.

Se você estiver lançando todos eles como produtos diferentes, recomenda-se ter várias ramificações. Se não, então ainda é recomendado usar algo como um tronco ou um ramo mestre.

Além disso, acho que isso dependeria do processo de desenvolvimento que você tem, particularmente da implantação. Se você tem um processo que permite que apenas uma ramificação seja lançada para produção e que as ramificações sejam tratadas como "compilações incrementais", o que significa que a liberação B não pode ser lançada para produção, a menos que a liberação A tenha sido lançada primeiro, A já está em B, então ter várias ramificações é o caminho a percorrer. Isso funcionará se você tiver equipes espalhadas por todo o mundo e geralmente você tiver alterações ordenadas por prioridade.

A solução com os três ramos diferentes (para produção, desenvolvimento e recursos) funciona muito bem. Vamos dizer que você descubra algum bug no seu código de produção, então você pode aplicar um patch para que, em seguida, liberá-lo. Apenas certifique-se de não incluir nenhum acréscimo de recursos na ramificação de produção ou quaisquer alterações importantes na ramificação de produção. Você e sua equipe terão que se autodisciplinar para não adicionar nenhuma mudança de recurso importante em sua filial de produção. O ramo de produção deve ser apenas para pequenas correções de bugs que não garantem uma grande mudança em sua base de código de produção.