Faz rebase para refrescar o teu ramo

Faço parte de várias equipas de software e, com muita frequência, submetemos código para o nosso ramo principal. Nas minhas equipas, o habitual é não ter um ramo develop nem sequer ciclos de lançamento. Em vez disso, lançamos com regularidade.

Isto não é prática comum numa grande empresa, mas nas empresas ágeis centradas em software é bastante normal.

A questão é como o fazemos sem pisarmos os calos uns aos outros.

Git

Resume-se ao git e ao agile. A ferramenta que usamos para gerir o controlo de versões e um bocadinho da mentalidade do nosso ciclo de gestão de projetos.

O Git é simplesmente uma maneira de detetar diferenças entre cópias. Se a cópia de produção contém A, o Joe está a trabalhar em B e a Sally em C, o Git consegue perceber as diferenças e juntar as cópias sem conflito.

O difícil é quando o trabalho é demorado e as contribuições são submetidas a intervalos diferentes.

É aí que entra o rebase. O git rebase origin/main garante que o meu trabalho, o trabalho que sai do main, está atualizado com tudo o que os meus colegas contribuíram. É a coisa certa a fazer e reduz o retrabalho no futuro quando surgem conflitos. Garante que o meu trabalho está atualizado antes de ser integrado no ramo main. A fonte de verdade.

Fluxo

Uma estratégia comum nas equipas é o git-flow. A Atlassian tem-no muito bem definido e não precisa de mais explicações.

Mas não me parece perfeito.

Na engenharia de software, às vezes tendemos a automatizar os processos que prezamos, como mecanismos para sermos mais produtivos. Funcionam bem, mas trazem as suas próprias falhas.

Por exemplo, um ramo de funcionalidade pode ser um bom mecanismo para testar uma funcionalidade específica, e cada commit pode disparar uma quase-implantação para demonstrar o potencial de alguma funcionalidade nova.

O resultado imperfeito é que o ramo de funcionalidade dispara algum processo automático para implantar essa funcionalidade de demonstração.

Isto é, ao mesmo tempo, caro e insuficiente.

Ramos de trabalho

Uma abordagem simples que estou a adotar na minha equipa são os ramos work/*. São um conceito parecido com os ramos de funcionalidade, mas com um espaço de nomes próprio para evitar os processos automáticos.

Os ramos de trabalho levam o prefixo work/ e ficam explicitamente fora das pipelines automáticas. Foram pensados para ser o “Guardar Automaticamente” do mundo do controlo de versões.

Incentivo ativamente as minhas equipas a trabalhar sobretudo no ramo work/* e só juntar funcionalidades ao ramo feature/* quando querem que uma pipeline corra.

Para concluir

Faço a ressalva de que só pratico isto nas minhas equipas há pouco tempo e, apesar do esforço extra de distinguir entre ramos feature/* e work/*, parece estar a funcionar bem.

Reconheço que os passos de bloqueio também são um bom mecanismo para reduzir implantações e builds desnecessárias. São ótimas maneiras de conseguir coisas parecidas, mas infelizmente não estão disponíveis nos ambientes em que trabalho.

Estou sempre disposto a ouvir opiniões e, quem sabe, sugestões de novas maneiras de trabalhar. Se tens ideias, fala comigo.