Rebasing, Cherry-Pick & Worktrees
Rebase, cherry-pick e worktrees ajudam equipes Go a manter um histórico linear, portar correções entre linhas de lançamento e trabalhar em duas versões de módulos simultaneamente.
//
Busque em todas as páginas da documentação
Rebase, cherry-pick e worktrees ajudam equipes Go a manter um histórico linear, portar correções entre linhas de lançamento e trabalhar em duas versões de módulos simultaneamente.
Usados com cuidado, eles reduzem a dor de conflitos em go.sum e aceleram hotfixes sem stashes sujos.
Rebase reaplica seus commits sobre uma base mais nova, reescrevendo SHAs.
Cherry-pick copia commits individuais para outra branch, comum para backports.
Worktrees adicionam um segundo diretório de checkout compartilhando um único armazenamento .git, ideal para execuções paralelas de go test em diferentes branches.
Todos os três interagem com pseudo-versões de módulos Go porque essas strings incorporam metadados de commit.
Cartão de receita de referência rápida - pronto para copiar e colar.
# Rebase da branch de feature na última main
git fetch origin
git switch feat/my-change
git rebase origin/main
go test ./...
go mod tidy && git diff --exit-code go.mod go.sum
git push --force-with-lease
# Cherry-pick de hotfix para a branch de release
git switch release/v1
git cherry-pick abc1234
go test ./...
# Checkout paralelo com worktree
git worktree add ../repo-hotfix release/v1Quando usar isso:
main para release/v1.Corrigir um panic nil em main, fazer backport para a linha de release v1, e manter o trabalho de feature em andamento:
# Em main - correção aplicada como commit fa1c0ff
git switch main
git pull --ff-only
go test ./...
# Backport para release/v1
git switch release/v1
git pull --ff-only
git cherry-pick fa1c0ff
go test ./...
git tag -a v1.9.4 -m "v1.9.4: corrige panic nil no parser"
git push origin release/v1 v1.9.4
# Continuar a branch de feature em um worktree
git worktree add ../widget-feat feat/new-api
cd ../widget-feat
go test ./...O que isso demonstra:
main na branch de release.Rebase remove temporariamente seus commits, avança para a nova base e reaplica os commits um por um.
Conflitos podem aparecer em fontes Go e go.sum; resolva, git add, git rebase --continue.
Cherry-pick aplica o patch de um commit escolhido como um novo commit na branch atual.
Se o commit original tocou go.mod, verifique o estado tidy após o pick.
Worktree cria um diretório de trabalho vinculado com seu próprio HEAD, mas compartilhando objetos e refs.
Cada árvore pode executar go build / go test independentemente; o cache de módulos é global na máquina.
| Situação | Orientação |
|---|---|
| Branch de feature pessoal antes do merge | Faça rebase livremente; use push com --force-with-lease |
| Branch para a qual outros já fizeram push | Coordene; prefira merge |
| Após tags que consumidores usam | Não reescreva commits com tag |
| PR aberto com muitos revisores | Faça rebase cedo e frequentemente, não apenas no final |
Cherry-pick traz um commit.
Merge traz o histórico completo da branch.
Para linhas de patch Go, cherry-pick mantém as branches de release mínimas e amigáveis ao changelog.
~/src/widget/ # trabalho principal em feat/new-api
~/src/widget-hotfix/ # worktree em release/v1
Liste os worktrees: git worktree list.
Remova: git worktree remove ../widget-hotfix após o término da branch.
# Após qualquer reescrita de histórico em uma branch da qual você depende localmente
go clean -testcache
go test ./...
# Pré-visualização da pseudo-versão para o HEAD atual (não fixado)
go list -m -json example.com/widget@masterReescrever SHAs altera as strings de pseudo-versão para commits sem tag.
Releases com tag não são afetadas depois de enviadas.
git push --force-with-lease.go.mod difere na branch de release. Correção: go test ./... e tidy após cada pick.go.sum - Mesclar manualmente linhas de checksum é propenso a erros. Correção: escolha um lado, execute go mod tidy, continue o rebase.| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
Merge main na feature | Branch compartilhada, baixa tolerância a reescrita | Você quer histórico de trunk linear |
git merge backport | Linha de release divergentemente grande | Correção de segurança de commit único |
| Stash | Troca rápida de contexto, minutos | Builds longos paralelos em duas branches |
| Clone separado | Experimentos completamente isolados | Desperdício de disco e tempo de fetch |
Releases semver com tag não mudam após o rebase, a menos que você mova ou exclua tags.
Commits sem tag acessados via pseudo-versões mostrarão novas strings de versão após mudanças de SHA.
Quando várias pessoas fazem commit na mesma branch ou quando preservar o contexto exato do merge é importante para auditorias.
Sim, se as saídas de protobuf ou stringer diferirem entre as branches.
Regenere com a toolchain da branch e continue o cherry-pick.
Dois ou três por repo é o típico: trunk, feature, hotfix.
Mais do que isso geralmente sinaliza problemas na política de branches.
Sim.
Trate branches com force-push como novos pushes; os grafos de módulo precisam ser revalidados.
Juntar commits de trabalho em andamento, reescrever mensagens, descartar commits de debug antes de um PR limpo.
Execute antes da revisão, não após o merge no trunk.
Cada worktree é um diretório separado.
Um arquivo go.work em uma árvore não se aplica a outra, a menos que você copie ou crie um link simbólico intencionalmente.
git cherry-pick --abort durante um conflito, ou git revert no commit ruim se já foi commitado.
Fazer rebase em commits antigos altera SHAs e pode confundir anotações manuais de bisect.
Use tags e commits de merge como âncoras estáveis para bisect.
Sim: git worktree add ../widget-v1 v1.9.3.
Útil para reproduzir um bug do consumidor em uma versão exata do módulo.
É útil se as verificações forem reexecutadas de forma confiável.
Certifique-se de que go mod tidy e os testes rodem após o rebase do bot, não apenas a resolução de conflitos.
Mesmas regras, mas os conflitos podem abranger múltiplos arquivos go.mod.
Execute tidy em cada raiz de módulo afetada após a resolução.
Versões do Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, modernizadores
go fix- verifique o patch na compilação), chi (última - verifique na compilação), gin (última - verifique na compilação), echo (última - verifique na compilação), google.golang.org/grpc (última - verifique na compilação), sigs.k8s.io/controller-runtime (última - verifique na compilação), kubebuilder (última - verifique na compilação), tinygo (última - verifique os alvos de placa na compilação), wazero (última - verifique na compilação) e golangci-lint (última - verifique o conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 18 de jul. de 2026