É tudo sobre contexto: com que frequência você libera e o que está em uma liberação.
Aqui está um pouco de um estudo de caso que eu tive com meu trabalho antigo, usando o método B (chamamos de ramificação por objetivo ).
Para colocar a história em contexto,
- Um lançamento consistia em novos recursos em nosso software: novos modos de jogo, novas funcionalidades, novas opções de configuração.
- O ciclo de lançamento foi bastante longo: nossos clientes eram universidades que mantinham um conjunto de recursos por um ano.
O desenvolvimento principal foi feito no tronco até atingirmos um estado completo do recurso para uma determinada versão. Nesse ponto, criaríamos uma ramificação, digamos projectname-january2012 e faríamos nossos testes de qualidade e correções de bugs nessa mesma ramificação. Quando estávamos prontos para um lançamento público, marcávamos o código nesse ramo e lançávamos.
No entanto, o desenvolvimento do lançamento não terminou nessa tag. Inevitavelmente, tivemos clientes que encontraram bugs ou pequenos problemas com o lançamento. Portanto, nesse caso, tudo o que precisamos fazer é voltar para esse ramo, corrigir o código e criar uma nova versão marcada do ramo janeiro de 2012 a ser lançada e mesclar as correções de volta ao tronco.
No nosso caso, essa abordagem foi favorável porque alguns usuários preferiram ficar com versões mais antigas com um conjunto limitado de recursos ou simplesmente porque o custo de implantar na infraestrutura uma versão totalmente nova em vez de um hotfix causou alguns problemas.
Portanto, as perguntas que você deve se fazer são:
- Com que frequência libero?
- Meus lançamentos serão 100% compatíveis com versões anteriores?
- Meus clientes ficarão bem com a atualização completa para corrigir bugs?
Se você liberar com frequência, talvez não valha a pena ter ramificações para cada um deles. No entanto, se o seu ciclo de lançamento for bastante longo, como o meu caso de uso antigo, e que a implantação, a compatibilidade com versões anteriores e os clientes que se apegam a lançamentos antigos podem ser riscos, a opção B certamente poupará muita dor, facilitará muito o suporte às coisas seus clientes a um custo mínimo para lidar com a confusão de filiais.