Modelo de ramificação (Branch)

Modelo baseado em http://nvie.com/posts/a-successful-git-branching-model/

Os branchs principais

Existem dois branchs principais que possuem ciclo de vida infinito e são paralelos entre si, origin/master e origin/develop

• Consideramos master como o branch principal onde o código fonte sempre reflete um estado pronto para produção.
• Consideramos develop como o branch principal onde o código fonte sempre reflete um estado com as últimas mudanças de desenvolvimento entregues para uma próximoa versão.

Quando o código fonte no develop atinge um ponto estável e está pronto para ser liberado, todas as alterações devem ser mergeadas no master de alguma forma, e em seguida, entiquetadas com o número da versão.

Branchs de apoio

Ao lado dos branchs principais o nosso modelo de desenvolvimento utiliza alguns branchs de apoio que servem para auxiliar o desenvolvimento paralelo entre equipes, facilitar o rastreamento de recursos, preparar releases para produção e ajudar a corrigir rapidamente problemas em produção, ao contrário dos branchs principais esses branchs possuem um ciclo de vida finito, e deve ser removido eventualmente.

Os diferentes tipos de branch de apoio são:

• Feature branches
• Release branches
• Hotfix branches

Feature branch

• Deve se ramificar de: develop
• Deve fundir com: develop
• Nomenclatura padrão: Qualquer nome exceto, master, develop, hotfix-* e release-*

São utilizadas para desenvolvimento de novos recursos, para a próxima versão ou uma versão futura, ao iniciar o desenvolvimento de um recurso a versão em que este será incorporado pode ser desconhecida. A idéia do feature branch é que ele exista enquanto o recurso estiver em desevolvimento, ao fim ele é mesclado em develop (para adicionar definitivamente o novo recurso a próxima versão) ou descartado (quando recurso não funciona).

Release branch

• Deve se ramificar de: develop
• Deve fundir com: develop e master
• Nomenclatura padrão: release-*

São utilizados para a preparação de uma nova versão de produção, eles permitem pequenas correções de bugs e preparação de meta-dados para uma versão (número de versão, data de compilação, etc), ao fazer esse trabalho neste branch, o branch principal develop é liberado para receber recursos de uma próxima grande versão.

O grande momento de criação deste branch é quando o desenvolvimento (quase) reflete o estado desejado da nova versão, pelo menos todos os recursos direcionados para nova versão devem está mesclados em develop neste momento, todos os recursos direcionados para lançamentos futuros, devem esperar este branch ser criado para que possam ser mesclados em develop

É exatamente no momento de criação deste branch que a próxima versão tem um número de versão atribuído, até o momento de criação da release branhc, o branch develop refletiu mudanças para uma próxima versão, mas não fica claro que está versão acaba de se tornar 0.3.0 até que o release branch seja criado. A decisão sobre a versão deve seguir o modelo adotado, e o commit alterando os arquivos necessários para versionamento deve ser realizado.

Hotfix branch

• Deve se ramificar de: master
• Deve fundir com: develop e master
• Nomenclatura padrão: hotfix-*

Os hotfix branch são bem parecidos com os feature branchs, já que eles também servem para gerar uma nova versão de produção, embora não planejada. Eles devem ser criados da necessidade em corrigir um bug critico na versão em produção.

A idéia é que o trabalhe de desenvolvimento de novos recuros possa continuar, enquanto essa correção é preparada e mesclada em produção (master), ao final ela deve ser mesclada ao branch de desenvolvimento (develop), fazendo com que o branch principal de desenvolvimento esteja alinhado com o branch principal de produção