Esse workflow Git pode resolver seus problemas

novembro 03, 2017   Dicas , Git

Recentemente estive debatendo com alguns colegas qual seria a melhor (ou a mais adequada) organização de branches no Git.

Primeiramente, embora clichê, o melhor workflow é aquele que a equipe de desenvolvimento constroi. Não adianta pegar algo pronto ou definido por um único dev e oficializar. O certo e desejável é que todos se reúnam e decidam a melhor estratégia.

Mas também é legal se inspirar em alguns modelos ou adaptar aqueles que você já tenha visto ou trabalhado. Por isso, trouxe um modelo para servir de inspiração para o seu grupo.

Master

Essa branch é a única conhecida pelo ambiente de produção. Na verdade, tem mais uma, que veremos na sequência.

Em ambiente de desenvolvimento, teremos como base a branch development

Development

Essa branch vai reunir todas as branches de desenvolvimento que surgem no dia-a-dia. Ela deve ser constantemente atualizada com as branches acima dela, que veremos mais tarde. 

Pense nela como a master do desenvolvimento. Você deve dar merge somente quando a sua branch filha estiver estável o suficiente.

Feat_*

As branches feat_ são as que trazem funcionalidades novas ao projeto. Uma nova rota, um novo comando, uma nova tela. Tudo que é novidade e não deve interferir (ou pouco interfere) no restante do projeto deve ser criado com esse prefixo.

Quando a branch estiver pronta ou madura o suficiente, ela fará merge na development. 

Fix_*

As branches fix_ são as que trazem correções ao projeto. Aquele botão que ficou com valor errado, aquela controller que precisou ser refatorada, aquela nova tabela que acabou trazendo um campo a menos. Aqui a meta é resolver bugs.

Quando a branch estiver pronta e os testes unitários forem válidos, ela fará merge na development.

Upstream

A branch upstream é uma cópia da master. Ela serve como homologação e é nela que as branches-filhas da development farão merge também. 

Vamos imaginar que foi criado um novo campo tamanho no formulário de pedido. Você criou uma branch feat_add_size_to_order. Feature implementada, testes OK. Hora de subir para a produção, certo? Errado! Faça um merge na upstream, pois é ela que vamos subir para a produção.

Hãm?

Os testes passaram, mas será mais interessante se fizermos um teste manual além dos famosos testes de CI. Na produção, na branch master, rodaremos:

git pull origin upstream

DEU RUIM! Algo inesperado aconteceu. No worries, basta voltar para a master, que está intacta.

git pull origin master

Está tudo certo novamente. Revise sua branch feat_add_size_to_order e repete o processo.

Ufa! Agora está tudo certo! Nesse caso, pode fazer o merge na master e pronto.

IMPORTANTE

Todas as branches novas devem fazer pull da master!  Lembre-se que ela está com o código mais estável de todos.

Além disso, é saudável para o seu projeto que todas as branches façam constantes pulls da master, mesmo que quebre o que você está desenvolvendo. Quanto menor o escopo, menor a chance de ocorrer um erro catastrófico na sexta-feira as 17h57.

MAIS IMPORTANTE

Esse workflow serve apenas como um guia. É evidente que em projetos maiores teremos Integração Contínua, diversos testes, pull-requests autorizados por diferentes níveis de acessos, protected branches, code coverage e tudo mais.

E aí, interessou? Discordou? Abriu uma luz no céu! Conta nos comentários o/