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

10 exemplos para você começar com Git e GitHub - 7 básicos e 3 intermediários.

Pré-requisitos

• Instale Git 2.40+ e Go 1.26.x de go.dev/dl.
• Configure a identidade: git config --global user.name "Você" e git config --global user.email "voce@exemplo.com".
• Tenha acesso SSH ou HTTPS ao seu host de módulo (GitHub, GitLab, etc.).
• Para módulos privados, defina GOPRIVATE para o prefixo da sua organização, por exemplo export GOPRIVATE=github.com/myorg/*.

Exemplos Básicos

1. Clone um repositório de módulo Go

Comece a partir do remoto que corresponde ao caminho do seu módulo go.mod.

git clone git@github.com:myorg/widget.git
cd widget
go test ./...

• A URL de clone deve corresponder a onde go get resolve o módulo.
• Execute testes imediatamente para verificar o acesso ao toolchain e ao cache de módulos.
• go.mod na raiz do repositório define o caminho do módulo para importações.

Relacionado: Git para Equipes Go - por que Git e módulos compartilham uma história de lançamento

2. Verifique o status antes de tocar em go.mod

Veja as alterações rastreadas e se os arquivos de dependência divergiram.

git status
git diff go.mod go.sum

• Diff de go.mod / go.sum geralmente significa alterações de dependência ou tidy.
• Binários não rastreados geralmente significam que .gitignore precisa de /bin/ ou *.exe.
• Comite alterações nos arquivos de dependência no mesmo PR das alterações de código que as causaram.

Relacionado: go.mod, go.sum & Seleção de Versão Mínima - o que esses arquivos significam

3. Crie um branch de recurso

Mantenha main liberável; crie um branch por alteração.

git switch -c feat/add-metrics

• Use nomes de branch curtos e descritivos (fix/nil-panic, feat/grpc-health).
• Uma única alteração lógica por branch mantém a revisão do PR e o bisect simples.
• Faça rebase ou merge de main frequentemente para evitar conflitos de go.sum.

Relacionado: Estratégias de Branching & Fluxo Baseado em Tronco - hábitos de fluxo baseado em tronco

4. Adicione e comite fontes Go

Comite unidades compiláveis com mensagens claras.

git add internal/metrics/collector.go internal/metrics/collector_test.go
git commit -m "metrics: add process collector"

• Inclua arquivos _test.go com o código que eles cobrem.
• Evite comitar binários de go test ou saídas de perfil.
• O estilo de mensagem pacote: verbo corresponde a muitas convenções de projetos Go.

5. Registre alterações de dependência

Após go get ou edições de importação, faça tidy e comite os arquivos de módulo.

go get golang.org/x/sync@v0.10.0
go mod tidy
git add go.mod go.sum
git commit -m "go.mod: bump golang.org/x/sync"

• go mod tidy remove requisitos não utilizados e adiciona indiretos ausentes.
• Revise o crescimento de go.sum para módulos transitivos inesperados.
• A CI deve falhar se o tidy alteraria arquivos após o merge.

6. Envie o branch e abra um PR

Publique o trabalho para revisão sem marcar uma versão ainda.

git push -u origin feat/add-metrics

• -u define o upstream para que git push / git pull posteriores funcionem sem argumentos extras.
• Abra um pull request contra main com o plano de teste e o impacto do módulo anotados.
• Espere pelo go test ./... da CI antes de fazer o merge.

Relacionado: Revisão de Código com PRs do GitHub - tamanho do PR e revisão ciente de módulos

7. Faça pull do trunk mais recente antes do merge

Integre as alterações de outros e reexecute os testes.

git switch main
git pull --ff-only
git switch feat/add-metrics
git merge main
go test ./...

• --ff-only em main evita commits de merge acidentais ao atualizar o trunk local.
• Resolva conflitos de go.sum cuidadosamente; reexecute go mod tidy após a resolução.
• Nunca faça merge com testes falhando ou diffs de tidy não commitados.

Exemplos Intermediários

8. Inspecione o histórico para uma regressão

Use o histórico do Git com o fluxo rápido de bisect do Go.

git log --oneline -n 10
git bisect start
git bisect bad
git bisect good v1.3.0
go test ./internal/parse -run TestDecode

• git bisect combina bem com flags focadas de go test por pacote.
• Nomes de tags como v1.3.0 são limites válidos para bisect de módulos lançados.
• Documente o resultado do bisect no PR de correção para leitores futuros.

Relacionado: Rebasing, Cherry-Pick & Worktrees - ferramentas de higiene de histórico

9. Crie uma tag de lançamento semver

Marque o commit que você deseja que os consumidores do módulo resolvam.

git switch main
git pull --ff-only
go test ./...
git tag -a v1.4.0 -m "v1.4.0: metrics collector"
git push origin v1.4.0

• Use tags anotadas (-a) para lançamentos; elas carregam metadados de mensagem e tagger.
• Marque apenas após a CI verde no commit exato.
• Os consumidores executam go get github.com/myorg/widget@v1.4.0 após o proxy indexar a tag.

Relacionado: Tags Assinadas & Lançamentos de Módulos Go - assinatura e comportamento do proxy

10. Stash WIP e use um worktree

Trabalho paralelo sem conflitar saídas de go build.

git stash push -m "wip metrics" -- internal/metrics
git worktree add ../widget-hotfix main
cd ../widget-hotfix
go test ./...

• Especifique caminhos no stash para evitar varrer experimentos não relacionados de go.mod.
• Worktrees fornecem um segundo checkout compartilhando um banco de dados .git.
• Cada worktree precisa de sua própria execução de go test; o cache de módulos é compartilhado.

Relacionado: Padrões Git de Monorepo com go work - múltiplos módulos, um repo

Versões da Stack: Esta página foi escrita para Go 1.26.x (Green Tea GC padrão, modernizadores go fix - 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).