Estratégias de Branching & Fluxo Trunk-Based
O fluxo trunk-based mantém o main sempre liberável enquanto os branches de features permanecem curtos.
//
Busque em todas as páginas da documentação
O fluxo trunk-based mantém o main sempre liberável enquanto os branches de features permanecem curtos.
Equipes Go combinam esse modelo com CI que executa verificações go test ./..., go vet e go mod tidy em cada push.
A maioria das bibliotecas e serviços Go são enviados a partir de um único branch de integração.
Desenvolvedores criam branches por horas ou dias, mesclam através de pull requests e marcam releases semver da mesma linha.
Branches de release de longa duração são reservados para versões principais suportadas, não para trabalho de features do dia a dia.
Esse ritmo corresponde à forma como os proxies de módulos escolhem versões a partir de tags no branch padrão.
Cartão de receita de referência rápida - pronto para copiar e colar.
git switch main && git pull --ff-only
git switch -c feat/short-lived-change
# edite, teste localmente
go test ./...
go mod tidy && git diff --exit-code go.mod go.sum
git push -u origin feat/short-lived-change
# abra PR, mescle quando a CI estiver verde, delete o branchQuando usar isso:
go.sum de branches desatualizados.v1.x a partir do main sem um branch de release GitFlow.Uma equipe de biblioteca envia melhorias na API de métricas:
# Dia 1
git switch -c feat/metrics-api
# implemente + testes
go test ./...
git push -u origin feat/metrics-api
# PR aberto, CI roda no ubuntu com Go 1.26.x
# Dia 2 - rebase no main atualizado
git fetch origin
git rebase origin/main
go test ./...
git push --force-with-lease
# Após aprovação
# squash-merge ou merge commit por política da equipe
git switch main && git pull
git tag -a v1.5.0 -m "v1.5.0"
git push origin v1.5.0O que isso demonstra:
main (trunk) contém o estado canônico do módulo.go test, lint e, frequentemente, detecção de desvio go mod tidy.Trunk-based não significa "commitar diretamente no main sem revisão".
Significa integrar frequentemente e evitar linhas paralelas de longa duração que divergem em dependências.
| Branch | Duração | Propósito |
|---|---|---|
main | Permanente | Fonte de integração + release |
feat/*, fix/* | Horas a poucos dias | Mudanças individuais |
release/v1 (opcional) | Meses a anos | Backports apenas de patches para versões principais antigas |
hotfix/* | Horas | Patch urgente, pode ser cherry-pick para o branch de release |
| Verificação | Por que é importante |
|---|---|
go test ./... | Captura pacotes quebrados antes da mesclagem |
go vet ./... | Verificações estáticas para erros comuns |
go mod tidy + diff | Evita desvios de dependência inesperados no trunk |
golangci-lint | Estilo da equipe e padrões de bugs |
| Detector de corrida (jobs selecionados) | Regressões de concorrência |
Squash-merge mantém o histórico do trunk com um commit por PR.
Rebase-merge preserva commits individuais quando eles já estão bem formados.
Rebaseie branches de features no main antes da mesclagem para expor conflitos cedo, especialmente em go.sum.
go.sum e arquivos gerados entram em conflito frequentemente. Correção: divida o trabalho em PRs menores ou mescle o main diariamente.go.mod - Mudanças de dependência ainda precisam de teste completo. Correção: filtros de caminho excluem apenas caminhos de documentação reais.--force-with-lease.| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| GitFlow (develop + release) | QA em estágio pesado com versões paralelas | Pequena biblioteca Go com releases contínuas do trunk |
| Branches de release por versão principal | Patches de v1 de longo prazo enquanto v2 evolui no trunk | Equipe não tem disciplina de cherry-pick |
| PRs Empilhados / Fluxo Graphite | Grande mudança dividida para revisão | CI não pode executar grafos parciais de forma barata |
| Commits diretos no main | Mantenedor solo, baixo risco | Repositório de equipe sem verificações obrigatórias |
Mire em um PR revisável, geralmente com menos de 400 linhas de mudança em Go.
Se for mais longo, divida por pacote ou comportamento usando feature flags.
Squash mantém o trunk legível e mapeia um PR para uma entrada no changelog.
Preserve o histórico de múltiplos commits quando os commits já são atômicos e as mensagens são curadas.
Não, se as tags em cada branch seguirem semver e os caminhos dos módulos permanecerem consistentes.
Documente qual linha principal cada branch de release mantém.
Exija revisões de PR, proíba force-push no main e exija status checks para teste + tidy.
Opcional: exija commits assinados ou tags assinadas para releases.
Aceite um lado, execute go mod tidy, reexecute os testes, commite o resultado do tidy.
Nunca edite manualmente linhas de checksum sem entender a mudança de dependência.
Sim, com caminhos de CI por módulo e documentação clara de tagging.
O desenvolvimento local com go.work não substitui a política de integração do trunk.
Quando a certificação de release leva semanas e várias versões recebem patches em paralelo.
Mesmo assim, mantenha o main próximo de ser liberável para reduzir o custo de mesclagem.
Crie branch a partir do commit de release ou do branch de release suportado, cherry-pick para o trunk, marque o patch semver.
Verifique go test ./... em ambas as linhas quando a manutenção dupla estiver ativa.
Flags permitem que o trunk integre trabalho incompleto sem expor o comportamento.
Go usa build tags ou configuração em tempo de execução; a duração do branch ainda pode ser curta.
Atualize README do módulo, gatilhos de CI e proteção de branch após renomeações de master para main.
Proxies de módulo seguem tags no branch padrão atual.
Contribuidores ainda usam forks e PRs.
Mantenedores integram ao trunk canônico rapidamente após a revisão.
Marque após a mesclagem quando as notas de release estiverem prontas.
Não marque no meio de um PR; consumidores precisam de commits que passaram pela CI completa no trunk.
Versões de Stack: Esta página foi escrita para Go 1.26.x (Green Tea GC padrão, go fix modernizers - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026