Rebase para manter sua branch em dia

Eu faço parte de alguns times de software e, com muita frequência, a gente commita código na branch principal. Em comum nos meus times: não ter uma branch develop nem ciclos de release. Em vez disso, a gente lança com regularidade.

Isso não é prática comum em uma grande corporação, mas em empresas ágeis e focadas em software é bem normal.

A pergunta é: como fazer isso sem um pisar no pé do outro?

Git

Tudo se resume a git e agile. A ferramenta que usamos para gerenciar o controle de versão e um pedacinho da mentalidade do nosso ciclo de gestão de projetos.

O Git é só um jeito de detectar diferenças entre cópias. Se a cópia de produção tem A, o Joe está trabalhando em B e a Sally em C, o Git consegue descobrir as diferenças e juntar as cópias sem conflito.

O difícil é quando o trabalho é longo e as contribuições são commitadas em intervalos diferentes.

É aí que entra o rebase. git rebase origin/main é um jeito de garantir que meu trabalho, o que sai da main, esteja atualizado com tudo que meus colegas contribuíram. É a coisa certa a fazer e reduz retrabalho quando os conflitos aparecem. Garante que meu trabalho está em dia antes de entrar na branch main. A fonte da verdade.

Fluxo

Uma estratégia comum nos times é o git-flow. A Atlassian tem isso muito bem definido e não precisa de mais explicação.

Mas não acho que seja perfeito.

Em engenharia de software, às vezes a gente automatiza os processos de que gosta, como mecanismos para ser mais produtivo. Funcionam bem, mas têm suas falhas.

Por exemplo, uma branch de feature pode ser um bom mecanismo para testar uma funcionalidade específica, então cada commit pode disparar um quase-deploy para mostrar o potencial de alguma funcionalidade nova.

O resultado imperfeito é que a branch de feature dispara um processo automático para fazer o deploy dessa demonstração.

Isso é caro e insuficiente ao mesmo tempo.

Branches de trabalho

Uma abordagem simples que estou adotando no meu time são as branches work/*. É um conceito parecido com o das branches de feature, mas com um prefixo próprio para escapar dos processos automáticos.

As branches de trabalho levam o prefixo work/ e ficam explicitamente fora dos pipelines automáticos. Foram feitas para ser o “Salvamento Automático” do mundo do controle de versão.

Eu incentivo ativamente meus times a trabalhar principalmente na branch work/* e só fazer merge das features na branch feature/* quando quiserem que um pipeline rode.

Para concluir

Aviso que só pratico isso nos meus times há pouco tempo e, apesar do esforço extra de diferenciar entre feature/* e work/*, parece estar funcionando bem.

Reconheço que passos de bloqueio também são um bom mecanismo para reduzir deploys e builds desnecessários. São ótimas formas de chegar a resultados parecidos, mas infelizmente não estão disponíveis nos ambientes em que trabalho.

Estou sempre disposto a ouvir feedback e, quem sabe, sugestões de novas formas de trabalhar. Se você tiver alguma ideia, entre em contato.