Fluxo de trabalho Git para desenvolvedores Go: do caos ao código limpo

Por que o fluxo de trabalho Git é um pesadelo para todo desenvolvedor Go?

Você já passou meio dia tentando entender por que a build na branch master quebrou, sendo que ontem tudo funcionava? Ou já se perdeu nas versões dos módulos Go quando dois desenvolvedores alteravam o mesmo pacote ao mesmo tempo? Parece familiar? Bem-vindo ao clube.

Go é uma linguagem simples e elegante. Mas sem um fluxo de trabalho Git para desenvolvedores Go adequado, até o código mais limpo vira um macarrão. Neste artigo, vamos explorar cenários reais: como trabalhar com go modules, como não quebrar o CI/CD e como tornar o code review rápido e produtivo. Aperte os cintos, vai ser prático.

O básico: Git Flow e sua adaptação para Go

O Git Flow clássico (branches main, develop, feature/*, release/*, hotfix/*) funciona muito bem para projetos grandes. Mas no mundo Go, existem algumas particularidades.

Por que o Trunk-Based Development geralmente vence?

A comunidade Go adora simplicidade. O Trunk-Based Development (trabalhar em uma branch principal com branches de funcionalidade de curta duração) combina perfeitamente com a filosofia do Go. Menos branches significam menos dores de cabeça com merges. Para equipes pequenas (até 5 pessoas), essa é geralmente a melhor escolha.

No entanto, se o seu ciclo de lançamento é de 2 semanas e você tem várias funcionalidades paralelas, o Git Flow continua sendo o rei. Apenas lembre-se: cada branch não deve viver mais do que 2-3 dias. Caso contrário, os conflitos são inevitáveis.

# Exemplo de criação de uma branch de funcionalidade para um novo middleware\ngit checkout -b feature/add-request-logger\n# Trabalhe, faça commit, envie\ngit push origin feature/add-request-logger\n# Após o code review — squash e merge na main\n

Go Modules e Git: Como não enlouquecer

O problema mais comum em um fluxo de trabalho golang git são as dependências. O Go Modules (a partir do Go 1.11) resolveu muitos problemas, mas também trouxe novos.

Trabalhando corretamente com tags

Seu módulo é uma API pública. Se você o altera, mude a versão. O versionamento semântico (semver) não é apenas moda, é obrigatório.

\n
• v0.x.x — versão instável, pode quebrar a compatibilidade.
\n
• v1.x.x — versão estável, compatibilidade reversa é obrigatória.
\n
• v2+ — mudanças principais, obrigatório alterar o caminho do módulo.
\n

Exemplo de marcação correta:

git tag v1.2.3\ngit push origin v1.2.3\n

E agora, um exemplo de como NÃO fazer:

# Ruim: tag sem sincronização com go.mod\ngit tag v1.0.0\n# Mas no go.mod ainda está a versão v0.5.0\n

Sempre atualize o go.mod primeiro, depois crie a tag. Caso contrário, o go get vai ficar maluco.

Como atualizar dependências em equipe

Suponha que você atualizou a biblioteca github.com/gin-gonic/gin. Em vez de enviar um diff enorme, siga a regra: um commit, uma alteração.

# Atualize uma dependência\ngo get github.com/gin-gonic/gin@v1.9.1\ngo mod tidy\ngit add go.mod go.sum\ngit commit -m "chore: atualiza gin para v1.9.1"\ngit push\n

Isso simplifica o code review: seu colega vê exatamente o que mudou, e não uma "mágica" no go.sum.

Code Review para Go: Fluxo de trabalho Git a serviço da qualidade

Code review não é sobre "encontrar bugs". É sobre compartilhar conhecimento e manter o estilo. Mas se o seu fluxo de trabalho git para projetos golang não estiver configurado, a revisão vira um inferno.

Como tornar a revisão rápida

\n
• PRs pequenos: 200-300 linhas de código é o máximo. Mais que isso, divida.
\n
• Linting automático: o golangci-lint deve rodar antes da revisão, não depois. Configure um hook de pre-commit ou CI.
\n
• Estilo único: use o gofmt (sim, é obrigatório). Sem discussões