Resumo dos Destaques de Git & GitHub

Todo ponto de destaque das 9 páginas desta seção, reunido em uma página e agrupado pela página de origem.

Git para Equipes Go

• Tags Git no seu branch padrão se tornam releases semver para go get
• Hashes de commit geram pseudo-versões quando tags Git não existem
• Alterações esquecidas em go.sum ou tags Git ruins quebram builds downstream
• Cherry-picks e rebases alteram hashes de commit, afetando pseudo-versões
• Assine tags Git para verificar a integridade da release antes que o proxy de módulo as cache
• Use retract em go.mod para evitar tags Git ruins sem reescrever o histórico

Noções Básicas de Git para Projetos Go

• URL de clone correspondendo à resolução de go get; verifique com go test imediatamente
• go.mod e go.sum diffs revelam alterações de dependência; comite com as alterações de código
• Use nomes de branch curtos com uma única alteração lógica; rebaseie frequentemente para evitar conflitos
• Comite _test.go com código; evite comitar binários ou perfis de teste
• go mod tidy remove requires não utilizados e adiciona indiretos ausentes; CI deve validar
• Use --ff-only ao fazer pull do main; reexecute go mod tidy após resolver go.sum

Estratégias de Branching & Fluxo Baseado em Trunk

• Mantenha o main sempre liberável com branches de recursos de curta duração mesclados frequentemente
• Execute go test, go vet e go mod tidy em cada push para capturar problemas antes do merge
• Rebaseie branches de recursos sobre o main antes do merge para expor conflitos cedo
• Fatia branches de recursos em PRs menores para evitar conflitos de go.sum e arquivos gerados
• Restrinja o force-push apenas a branches pessoais para evitar quebrar PRs abertos
• Reserve branches de release de longa duração apenas para backports de versões principais suportadas

Rebase, Cherry-Pick & Worktrees

• Rebase reescreve SHAs, alterando pseudo-versões de módulos Go para commits sem tag
• Cherry-pick copia commits únicos para backports limpos versus o histórico completo do merge
• Worktrees permitem execuções paralelas de go test em branches diferentes a partir de um único repositório
• Use git push --force-with-lease para evitar sobrescrever silenciosamente o trabalho de colegas de equipe
• Coordene rebases em branches compartilhados, rebaseie livremente em recursos pessoais apenas

GitHub Actions para Repositórios Go

• GitHub Actions executa go test, lint e verificações de módulo em cada push e PR
• Alinhe a CI ao floor da toolchain do módulo com go-version-file em vez de codificar
• Cacheie arquivos go.sum aninhados em repositórios multi-módulo para acelerar downloads de módulos
• Jobs de lint separados rodam em paralelo com os testes sem bloquear o início dos testes
• Pushes de tags disparam jobs de release usando goreleaser após os testes passarem
• Para módulos privados, defina GOPRIVATE e configure o git com um token PAT com escopo

Revisão de Código com PRs do GitHub

• Mantenha pull requests com menos de 400 linhas; fatie por pacote ou flag de recurso para evitar atrasar o trunk
• Revise alterações de API exportada e bumps de versão de go.mod quanto ao impacto de compatibilidade nos consumidores de módulos
• Verifique o wrapping de erros com %w, o ciclo de vida de goroutines, o cancelamento de contexto e data races
• Exija testes baseados em tabelas cobrindo caminhos de erro com a flag -race antes de aprovar
• Examine funções exportadas não testadas em diffs para evitar carimbar cegamente CI verde
• Inspecione alterações em massa de go.sum para capturar trocas na cadeia de suprimentos ou adições de peso transitivo

Tags Assinadas & Releases de Módulos Go

• Marque releases com semver (v1.2.3) no seu branch padrão para controlar as versões dos módulos Go
• Assine tags com git tag -s para verificar a autenticidade e integridade da release
• Bumps de versão principal exigem o caminho /v2 nas importações de módulo e tags v2.0.0 correspondentes
• A versionamento semântico de importação mantém v0/v1 em example.com/lib mas v2+ em example.com/lib/v2
• Retrate releases ruins em go.mod para alertar os consumidores sem excluir o histórico
• Tags assinadas autenticam refs VCS, não arquivos; go.sum e sumdb lidam com hashing de conteúdo

Padrões Git de Monorepo com go work

• Use go.work localmente para substituir diretivas replace entre módulos em arquivos go.mod comitados
• GOWORK=off simula o que os consumidores de módulos experimentam
• Evite replace em go.mod para caminhos locais, pois isso quebra go get para usuários externos
• Marque e faça CI de cada módulo explicitamente para que proxies e consumidores resolvam as versões corretas
• Uma única tag para módulos não relacionados significa que os consumidores não podem fixá-los independentemente
• Comite go.work quando toda a equipe compartilha o layout do workspace

Melhores Práticas de Git & GitHub

• Nunca faça merge no trunk sem que a CI verifique go test e tidy
• Mantenha o main liberável passando nos testes e nas verificações de module tidy
• Use branches de recursos de curta duração para minimizar conflitos de go.sum
• Comite go.mod e go.sum juntos com as alterações de código de dependência
• Envie tags explicitamente com git push origin v1.2.3 não por padrão
• Use caminhos de importação /v2 ao fazer alterações de API incompatíveis

3730363230327c3030356f6967637c6f692e73656469756765646f63