Modelo de branches no GitLab

O git mudou a forma com a qual os desenvolvedores pensam a respeito de merges e branches. No mundo de código centralizado, merges e branches sempre foram considerados assustadores (cuidados com os conflitos do merge) e algo que era feito apenas uma vez em um longo tempo. Porém com o git essas ações são extremamente baratas e simples, e são consideradas o cerne do dia-a-dia de trabalho, de verdade. Como uma consequência de sua simplicidade e natureza repetitiva, criar branches e merges não é algo que se deva ter medo. As ferramentas de versionamento dispõem de toda a assistência necessária para realizar as tarefas de criação de branches e merges. Mais informações sobre o git e ferramentas de controle de código podem ser facilmente encontradas na web.

Após essa breve introdução sobre a ferramenta, vamos entrar de cabeça no modelo de desenvolvimento. O modelo aqui apresentado é essencialmente nada mais que um conjunto de procedimentos que cada membro da equipe tem que seguir a fim de chegar a um processo de desenvolvimento de software gerenciado.

Descentralizado, mas centralizado

O modelo de repositório utilizado para o gerenciamento de branches considera que temos apenas um único, e verdadeiro, repositório central. Note que este repositório é apenas considerado central (pois como o git é uma ferramenta de controle descentralizado, não existe um repositório central a nível técnico). Vamos nos referir a este repositório principal como origin, pois é um nome familiar a todos os usuários do git.

Cada desenvolvedor efetua pull e pushes no origin. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também efetuar um pull das modificações realizadas por outros desenvolvedores de outras equipes. Por exemplo, isto pode ser útil quando um ou mais desenvolvedores estão trabalhando em uma nova grande funcionalidade, antes de enviar as alterações em progresso diretamente para o repositório origin prematuramente. Na figura acima, existem equipes de Alice e Bob, Alice e David, e Clair e David. Tecnicamente isto significa nada mais que Alice definiu um git remote (chamado bob) apontando para o repositório da equipe de Bob, e vice-versa.

O branch principal

No núcleo, o padrão de desenvolvimento é muito inspirado por modelos existentes no mercado. O repositório central detém dois branches principais, com uma vida útil infinita:

• master
• develop

O brach master no origin deve ser familiar para todo usuário git. Paralelamente ao branch master outro branch existe, chamado develop. Consideraremos o origin/master como main branch, onde o seu conteúdo sempre reflete o status de pronto para produção. Consideraremos o origin/develop como o principal branch onde o código fonte sempre reflete um estado com as mudanças de desenvolvimento mais recente entregues para a próxima sprint. Podemos chama-lo também de integration branch. É neste branch onde qualquer rotina noturna automática de build é executada. Quando o código-fonte no develop branch chega a um ponto estável e está pronto para ser lançado todas as alterações devem sofrer o merge com o branch master de alguma forma e, em seguida, ser marcado com um número de versão. Como isto é feito em detalhes será discutido mais adiante.

Portanto, cada vez que as alterações são mescladas de volta para o master', esta é uma nova versão de produção por definição. Devemos ser muito rigorosos com isso, de modo que, teoricamente, nós poderíamos usar um script automático para realizar o deploy e roll-out de nosso software para os nossos servidores de produção automaticamente toda vez que houve uma consolidação no master.

Os branches de suporte

Ao lado do master e develop branches, o nosso modelo de desenvolvimento utiliza uma variedade de branches de apoio para auxiliar o desenvolvimento paralelo entre os membros da equipe, facilitando o rastreamento de recursos, o preparo para versões de produção e para auxiliar na solução rápida de problemas na produção. Ao contrário dos branches principais, estes sempre tem um tempo de vida limitado, uma vez que eles serão removidos eventualmente. Os diferentes tipos de branches que podemos utilizar são:

• Feature branches
• Release branches

Cada um desses ramos têm um propósito específico e estão vinculados a regras restritas sobre quais branches podem ser seu branch de origem e quais branches devem ser considerados seu destino para receber o seu conteúdo por merge.

De nenhuma maneira estes branches são considerados especiais do ponto de vista técnico. Os seus tipos são classificados pela forma como os mesmos são utilizados.