Melhores Práticas de Git & GitHub
Hábitos portáteis de Git e GitHub para repositórios de módulos Go.
//
Busque em todas as páginas da documentação
Hábitos portáteis de Git e GitHub para repositórios de módulos Go.
Estas regras mantêm o trunk liberável, os gráficos de módulos organizados e as releases confiáveis para go get downstream.
main sempre liberável. Cada merge deve passar go test ./... e verificações de tidy do módulo no CI.go.sum.release/vN existe e como os patches são cherry-pickados do trunk.internal/parse: reject empty input.go.mod e go.sum com o código que causou as alterações de dependência. Nunca divida entre merges não percebidos.retract e tags de correção futura.--force-with-lease apenas em branches de feature pessoais. Nunca em branches compartilhados ou de release.go.mod.v1.2.3 correspondendo à linha principal do go.mod.git tag -a ou git tag -s.git push origin v1.2.3 - tags não são padrão em push simples./v2 para alterações incompatíveis na API. Não quebre consumidores sob o caminho de importação v1.go.mod em vez de excluir tags. Documente a migração no changelog.go do go.mod. Use go-version-file em setup-go.go.sum. Inclua somas aninhadas em monorepos.GOPRIVATE para módulos da organização e escopo estreitamente. Evite desabilitar sumdb para dependências públicas.GOWORK=off antes de marcar módulos de monorepo. Simula a resolução do consumidor..gitignore ciente de Go. Binários, perfis, ruído de IDE; nunca ignore go.sum..gitattributes para go.sum, se necessário. union reduz linhas de conflito manuais.replace específicos da máquina. Use go.work localmente ou arquivos de workspace commitados pela equipe.go.mod.-ldflags de git describe ou env de CI.Nunca faça merge para o trunk sem um CI que execute go test ./... e falhe em caso de drift de tidy.
Todo o resto suporta esse portão.
Squash mantém o trunk legível para bibliotecas.
Escolha rebase-merge se o histórico em nível de commit for curado e os revisores quiserem arqueologia granular.
Bibliotecas: quando a API ou correções justificam semver.
Serviços: marque commits implantáveis; os consumidores podem ser apenas internos.
Commits assinados ajudam na proveniência.
Tags de release assinadas geralmente têm ROI maior para consumidores de módulos do que assinar cada commit.
Caminhos por módulo para go.mod e pacotes exportados.
Exija revisão do proprietário quando a API pública ou as dependências mudarem.
Útil com CI e revisão humana em mudanças transitivas.
Merges cegos arriscam surpresas na cadeia de suprimentos.
Mantenedores fazem cherry-pick ou merge de PRs de forks após o CI.
Não conceda segredos a fluxos de trabalho de forks não confiáveis.
CI air-gapped, ambientes regulamentados ou recuperação de desastres fixada.
Documente a cadência de atualização do fornecedor no README.
Habilite quando muitos PRs são mesclados por hora e os testes do trunk são confiáveis.
Requer duração consistente do CI sob SLA da equipe.
Use a mesma string semver sempre que possível.
Construa imagens a partir de SHAs marcados no CI, não de heads de branch flutuantes.
Quando toda a equipe compartilha os mesmos módulos do workspace.
Supersetos pessoais permanecem não rastreados.
Marcar antes da migração do caminho /v2 em uma alteração que quebra compatibilidade.
Consumidores fixam gráficos de importação quebrados.
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 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: 18 de jul. de 2026