Git flow — um bem necessário

Eduardo Lombardi
4 min readOct 28, 2021
Photo by Pankaj Patel on Unsplash

Não sabe o que é git flow? Esse termo deveria estar no seu vocabulário, enraizado. Basicamente, quando utilizamos git estamos em uma plataforma aberta que permite a alteração de código desenfreada no maior estilo go-horse. O git flow cria (com a ajuda de ferramentas) um fluxo de desenvolvimento de modo a tentar organizar a subida de código, ajudando a manter a qualidade do software entregue. Acha complicado trabalhar com git? Aqui tem um artigo que explica os principais comandos utilizados no dia a dia de um desenvolvedor. O entendimento e a boa utilização do git são fundamentais para a boa manutenção de um git flow.

A branch main (que também pode ser chamada de master) é a principal de qualquer projeto. A primeira a ser criada no repositório. Nela deve ficar somente código que já passou pelo maior número de validações possível, e dela deve se extrair pacotes que serão entregues aos usuários. As validações aqui mencionadas devem ir desde um Code review em um Pull Request, até uma validação por um ou mais analistas de qualidade, seja ela manual ou automatizada. Geralmente quando trabalhamos de maneira autônoma, ou ainda em uma equipe enxuta, as vantagens da criação do fluxo ficam pouco evidentes. O real ganho aparece quando nosso software cresce bastante e chegam 200 desenvolvedores pra te ajudar na manutenção e atualização do mesmo. A escolha do fluxo a ser seguido para que o código chegue na branch main é arbitrária, mas aqui vão algumas dicas que vão diminuir a sua dor de cabeça com bugs indesejados.

  • Priorize sempre a separação de responsabilidades. Procure criar branches que resolvam problemas pontuais, ou pequenas partes de um problema. Isso ajuda muito na avaliação do código por um colega. Cansado, vai olhar as suas alterações e descobre que tem que revisar mais de 300 alterações. Nem o seu trabalho foi bem feito, nem o dele será.
  • Priorize o code review. Exigir que todo mundo pare o que está fazendo para fazer uma análise criteriosa da sua implementação é uma utopia, mas você deve ter ao menos uma branch intermediária que só recebe o código após a análise de pelo menos um colega. Quanto mais gente analisando a sua solução, mais chances de problemas serem encontrados antes da mesma chegar na mão do cliente.
  • Testes unitários são nossos aliados nessas horas. No momento do Code review, avalie se nenhum teste foi quebrado e se o novo conteúdo está sendo coberto com testes. Para estes casos, ter um fluxo em que anteriormente ao code-review uma máquina realize um build do target principal e do target dos testes apresentando o resultado ajuda. (Para se aprofundar um pouco em testes unitários, veja este artigo).
  • Se possível, faça testes após a integração das branches menores em uma branch concentradora. Podem ser detectados problemas e imprevistos após a junção dos pequenos pedaços de código.
  • Tenha uma branch abaixo da main(ou master) configurada de maneira que também possa se extrair pacotes à serem avaliados diretamente pelo cliente. Esta dica diminui a dor de cabeça, permitindo que o cliente dê o aval para a subida da versão ou negue o mesmo, caso encontre um problema crítico.
  • Mantenha um canal aberto de fácil comunicação entre todos os desenvolvedores do projeto e o pessoal da sustentação. Podem surgir demandas de alterações em partes compartilhadas do projeto, gerando conflitos. A resolução de conflitos nada mais é do que uma conversa entre as duas partes envolvidas para saber qual é a verdadeira e deve permanecer.

Vale lembrar que o git é livre e permite a configuração dos processos a serem utilizados na sua empresa/equipe de forma arbitrária, mas isso não significa que cada um pode fazer da sua maneira. O interessante é conversar com o pessoal responsável por sustentar o projeto para definir um padrão que deverá ser seguido por todos. A padronização e definição dos fluxos e processos por mais lenta que pareça vai permitir a evolução, deixar o projeto mais escalável e previnir o surgimento de bugs indesejados (para saber mais sobre bugs, leia este artigo). Quando forem chegando novos desenvolvedores, fica fácil explicar o modo de trabalho e garantir que a entrega dos mesmos saia com o mínimo de qualidade.

--

--