Git para Equipes Go
Equipes Go tratam o Git como a fonte da verdade para o código e para versões de módulos.
//
Busque em todas as páginas da documentação
Equipes Go tratam o Git como a fonte da verdade para o código e para versões de módulos.
Tags no branch padrão se tornam releases semver que go get e proxies de módulos consomem.
Esse acoplamento molda como você faz branch, revisa, tag e conecta a CI em torno de go.mod e go.sum.
go.sum quebra builds downstream; um histórico limpo acelera o bisect e a automação de releases.go list -m resolveu uma versão, ou padronizar verificações de PR para repositórios Go.go mod tidy e política de proxy/sumdb. Monorepos grandes trocam o tagging simples por coordenação multi-módulo.Um módulo Go é uma árvore de diretórios com go.mod na raiz.
Consumidores fixam seu módulo com uma string de versão que geralmente vem de uma tag Git no branch padrão do seu repositório.
O comando go mapeia tags v1.2.3 para versões de módulos e constrói pseudo-versões a partir de hashes de commit quando nenhuma tag existe.
O Git, portanto, faz um duplo dever: ele armazena o código-fonte e nomeia os releases.
Equipes padronizam em um trunk (geralmente main) que sempre passa em go test ./... e gates de lint relacionados.
O trabalho de features acontece em branches de curta duração mesclados via pull requests.
Branches de release são opcionais; muitas bibliotecas Go tag diretamente do trunk após revisão.
.gitignore tipicamente exclui binários (/bin/, *.exe), vendor/ quando não commitado, pastas de IDE e overrides locais de go.work quando estes são específicos do desenvolvedor.
go.mod e go.sum são sempre rastreados.
Para módulos privados, GOPRIVATE e credenciais de VCS devem se alinhar com como a CI clona e como os desenvolvedores se autenticam.
Quando você envia a tag v1.4.0, proxies de módulos (e go get direto) buscam aquele snapshot de commit.
Caminhos de importação devem corresponder ao caminho do módulo em go.mod; tags no branch errado ou sem diretivas go atualizadas em go.mod podem confundir consumidores.
Versionamento semântico de importação significa que módulos v2+ vivem sob um sufixo de caminho /v2; tags Git ainda usam semver no estilo v2.0.0.
Pull requests devem mostrar diffs de go.mod / go.sum claramente porque esses arquivos afetam todo build downstream.
A CI roda em cada push para validar o grafo de módulos antes do merge.
# Verificações típicas pré-merge (local ou CI)
go test ./...
go vet ./...
go mod tidy && git diff --exit-code go.mod go.sumMonorepos podem conter múltiplos arquivos go.mod ou um go.work raiz para desenvolvimento local.
O Git ainda tem um histórico, mas cada módulo pode tag independentemente.
Cherry-picks e rebases interagem com pseudo-versões: timestamps e hashes de commit mudam qual string de pseudo-versão o proxy serve.
Regras de branch protegido (reviews obrigatórios, status checks obrigatórios) substituem a cultura informal de "não quebre o main" com gates aplicáveis.
Tags assinadas (git tag -s) ajudam consumidores e equipes de segurança a verificar a integridade do release antes que um proxy de módulos cache a versão.
Retract em go.mod direciona novas resoluções para longe de uma tag Git ruim sem reescrever o histórico.
Ambientes air-gapped ou regulamentados podem fazer vendor de módulos; o fluxo Git então inclui PRs periódicos de atualização de go mod vendor com revisão de checksum.
| Abordagem | Força | Fraqueza | Melhor Encaixe |
|---|---|---|---|
| Trunk-based + tag no main | Releases rápidos, uma linha de integração | Requer CI forte e PRs pequenos | Bibliotecas e a maioria dos serviços |
| Branch de release por major | Janela de estabilização para patches | Drift de tags entre branches | Produtos empresariais de longo suporte |
| Monorepo + go.work | Mudanças atômicas entre módulos | Tagging complexo por módulo | Equipes de plataforma com libs compartilhadas |
| Fork + replace (temporário) | Desbloqueia patches de emergência | Não publicável; fácil de esquecer | Fluxos de contribuição de curta duração |
Hooks de observabilidade: grave a versão do módulo em builds de binários com -ldflags de git describe ou variáveis de ambiente de CI para que logs de produção correspondam ao estado do VCS.
v1.2.3); tags leves e nomes não-semver são ignorados ou se comportam inesperadamente para go get.retract e uma tag corretiva.go.sum para builds reproduzíveis e verificados.Consumidores de módulos resolvem versões a partir de tags no seu branch padrão.
Sem tags semver, apenas pseudo-versões de hashes de commit estão disponíveis, que são mais difíceis de comunicar em changelogs e políticas de suporte.
Branches de longa duração divergem do trunk, aumentam conflitos de merge em go.sum e atrasam a integração de correções de segurança.
Equipes Go preferem dias, não semanas, com CI provando que o módulo ainda compila e testa limpo.
go.mod e go.sum para qualquer alteração que modifique dependências.
Código-fonte para pacotes que você exporta, e bumps de diretiva go quando você adota novos recursos da linguagem.
GOPRIVATE diz ao comando Go para pular o banco de dados de checksum público e o proxy de módulos para caminhos de módulo correspondentes.
Suas credenciais Git (tokens HTTPS ou SSH) devem permitir que a CI e laptops clonent esses repositórios privados.
Muitas bibliotecas Go tag patches do main após cherry-picking ou PRs de correção diretos.
Branches de release ajudam quando você precisa suportar múltiplas linhas major com diferentes cadências de patch.
Pseudo-versões codificam o tempo e o hash do commit (por exemplo, v0.0.0-20240312120000-abcdef123456).
Elas permitem que go get fixe commits sem tag de forma reproduzível.
Apenas se você intencionalmente mantiver releases em lockstep.
Módulos independentes geralmente tag independentemente; documente a quais caminhos cada tag se aplica.
PRs mesclados mudam o conteúdo do módulo no trunk.
A próxima tag semver nomeia o release que os consumidores instalam; descrições de PR devem notar impacto na API ou em go.mod.
Em branches de feature pessoais antes da revisão, às vezes.
Nunca em branches compartilhados ou após uma tag de versão que consumidores já possam resolver.
.gitattributes para estratégia de merge de go.sum (union), ignores de blame para protobufs gerados e hooks ou CI rodando go mod tidy antes do merge.
go.work permite edições locais multi-módulo sem commits de replace.
Mantenha go.work opcional fora de branches compartilhados, a menos que toda a equipe use o mesmo layout de workspace.
Geralmente você não rastreia.
Construa artefatos de release em CI a partir de fontes taggeadas; armazene binários em armazenamento de artefatos, não no repositório de módulos.
Versões de Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, go fix modernizers - verifique o patch na build), chi (última versão - verifique na build), gin (última versão - verifique na build), echo (última versão - verifique na build), google.golang.org/grpc (última versão - verifique na build), sigs.k8s.io/controller-runtime (última versão - verifique na build), kubebuilder (última versão - verifique na build), tinygo (última versão - verifique os alvos de placa na build), wazero (última versão - verifique na build) e golangci-lint (última versão - verifique o conjunto de linters na build).
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026