Branching & Merging
As equipes Rust geralmente usam o fluxo trunk-based em main com branches curtas feat/*, trens opcionais release/* para workspaces com múltiplos crates e rebase para manter o histórico revisável.
Receita
git checkout main
git pull --rebase origin main
git checkout -b feat/billing-tax
# work, commit
git fetch origin
git rebase origin/main
git push -u origin feat/billing-tax
# open PR -> squash merge to mainQuando usar isso:
- Ao iniciar o trabalho em qualquer ticket
- Ao preparar um PR para revisão
- Ao coordenar releases de API + worker + migração
Exemplo de Trabalho
# Release train for workspace 2.6.0
git checkout -b release/2.6.0 origin/main
# only bugfixes cherry-picked
git tag v2.6.0
git push origin v2.6.0
# Hotfix from production tag
git checkout -b hotfix/2.5.1 v2.5.0
git cherry-pick <fix-sha>
git push origin hotfix/2.5.1O que isso demonstra:
- Branches de funcionalidades são criadas a partir do
mainmais recente - Branch de release estabiliza antes da tag
- Branches de hotfix são criadas a partir da tag de produção, não do
mainà frente da produção
Mergulho Profundo
Estratégias de Merge
| Estratégia | Quando |
|---|---|
| Squash merge | Um commit por ticket em main |
| Rebase merge | Preservar a granularidade do commit |
| Merge commit | Branches compartilhadas de longa duração |
Coordenação Específica de Rust
Quando as migrações sqlx e os deploys de binários precisam se alinhar, crie release/* e execute cargo test --all-features completo antes de marcar a tag.
Armadilhas
- Branches de funcionalidades de longa duração - conflitos de
Cargo.lockse multiplicam. Correção: rebase diariamente. - Fazer merge de
mainemrelease/*- traz funcionalidades não testadas. Correção: apenas cherry-pick de correções. - Rebase após aprovação de PR - invalida o SHA da revisão. Correção: rebase antes da aprovação final ou da fila de merge.
- Force push em
main- pesadelo de auditoria. Correção: a proteção de branch bloqueia o force push. - Discrepância de versão entre binário e lib - esqueceu de incrementar o crate do workspace. Correção: checklist de release para todos os membros do workspace.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| GitFlow | Governança pesada de release | Equipe pequena de deploy contínuo |
| Trunk only | Serviço binário único | Release coordenado de múltiplos artefatos |
| Merge queue | Monorepo de alta concorrência | Equipe minúscula |
FAQs
Rebase ou merge para PR?
Política da equipe: squash para main é comum; rebase localmente antes do merge para manter o CI verde.
Múltiplos PRs no mesmo branch?
Evite; um ticket por branch simplifica a revisão e o rollback.
Branches de crates do workspace?
Um único branch pode tocar múltiplos crates; incrementos de versão em um PR quando acoplados.
Relacionados
- Comandos Essenciais do Git
- Checklist de Resolução de Conflitos de Merge
- Release & versionamento
- Melhores Práticas do Git
Versões do Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.