Conceitos Git Flow

Teoria

É muito comum vermos desenvolvedores utilizando somente um branch para fazer commits em projetos pessoais. Isto não é errado, é muito tranquilo de se controlar tudo em uma branch quando se está desenvolvendo sozinho, mas o cenário muda bastante quando temos que interagir com mais contribuidores, seja em um projeto opensource ou privado.

Nessas horas é importante que se tenha total controle do que está sendo produzido por sua equipe, onde, ao mesmo tempo são corrigidas falhas, implementadas novas funcionalidades e o ideal é ter o seu código de produção com total funcionamento entregue ao cliente.

É ai que o Fluxo de git flow nos ajuda, olhe a imagem abaixo para entender melhor:

As branches principais

A master deve ser o principal ramo onde o código-fonte sempre reflete um estado pronto para produção que, versionado, será entregue ao cliente.

A develop deve sempre conter o código mais atual, onde as branchs de features serão ramificadas tendo ela como base.
Quando o código-fonte na develop atinge um ponto estável e está pronto para ser liberado, todas as alterações devem ser mescladas na master alguma forma e marcadas com um número de release.
Como isso é feito em detalhes será discutido mais adiante.

As branches de apoio

Junto às principais branches master e develop, há diversas de filiais de apoio para auxiliar o desenvolvimento paralelo entre os membros da equipe, facilitar o rastreamento de recursos, preparar releases de produção e ajudar a corrigir rapidamente problemas de produção ao vivo.

feature: para novas implementações
release: para finalizar o release e tags
hotfix: para resolver problema crítico em produção que não pode esperar novo release

Para saber mais sobre cada uma das branches de apoio, avance para o próximo post.