Melhores Práticas de Git & GitHub
Um resumo condensado das 25 práticas mais importantes de Git e GitHub para equipes móveis do Expo SDK 57 - extraído de todas as páginas desta seção.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 práticas mais importantes de Git e GitHub para equipes móveis do Expo SDK 57 - extraído de todas as páginas desta seção.
main é sempre a verdade da integração: Todo PR mesclado deve passar no CI; nunca deixe main quebrado durante a noite - os pipelines de loja e OTA assumem um tip verde (Fundamentos de Git para Equipes Móveis).
Commite o lockfile: package-lock.json (ou pnpm-lock.yaml) é necessário para npm ci reproduzível em Fundamentos de CI/CD Mobile - nunca o ignore no gitignore.
IDs de Ticket em cada commit: feat(checkout): summary sheet [SHIP-412] - cherry-picks para release/* e hotfix/* dependem de mensagens rastreáveis.
Squash merge de features para main: Um ticket, um commit no branch de integração - simplifica o cherry-pick para as lanes de release e hotfix.
Branches de feature de curta duração: Alvo de 1–3 dias; faça rebase ou merge de main diariamente para evitar conflitos em app.json, pastas nativas e eas.json.
Crie release/X.Y antes do freeze: O branch de release contém o candidato para a loja; novas features entram apenas em main até que o trem seja enviado (Calendário do Trem de Release).
Code freeze é uma política de Git: Durante a Revisão da App Store, release/* aceita apenas correções de bugs - aplique com proteção de branch, não com lembretes no Slack.
Cherry-pick - nunca mescle main em release/*: Mesclar puxa features não testadas para o candidato da loja; escolha SHAs explícitos listados no ticket de release.
Tag a partir de release/* após aprovação de QA: v2.6.0 aciona o CI de release do EAS; a mensagem da tag inclui o build_id testado pelo QA (Promoção Automatizada da Loja).
Mescle release/* de volta para main após o rollout: Fast-forward ou merge commit preserva o limite do trem; exclua o branch de release quando o rollout de 100% for concluído.
Branches Hotfix a partir de tags: git checkout -b hotfix/2.4.2 v2.4.1 - não de main ou release/2.5.0 - garante runtimeVersion e baseline nativo corretos (Fluxo do GitHub & Branches de Release).
Lanes de hotfix paralelas por minor ativo: Quando 2.4.x e 2.5.0 RC coexistem, separe hotfix/2.4.* e release/2.5.0 - um hotfix aberto por minor por vez.
Faça backport de todo hotfix: Cherry-pick o SHA da correção para main (se ainda não estiver lá) e para release/* aberto - o OTA de produção por si só não protege o próximo binário da loja.
Mapeie branches Git para canais OTA: O canal de produção publica de hotfix/* ou branch de produção documentado - nunca de feat/* (Canais e Branches de Release).
Nunca force push em main, release/* ou hotfix/*: Reescrever o histórico compartilhado quebra trilhas de auditoria, tags e linhagem de bundles OTA.
Upgrades de SDK em spike/* + worktrees: git worktree add mantém main aberto para features enquanto expo upgrade é executado isoladamente (Rebase Interativo & Worktrees).
Rebase interativo apenas em branches privados: Faça squash de WIP antes do PR com git rebase -i origin/main; use --force-with-lease, nunca --force em branches compartilhados.
Portas Metro separadas por worktree: EXPO_PACKAGER_PORT=8082 no worktree de spike - evita colisões de packager com o trabalho diário de feature.
Hooks de pré-commit espelham o CI: Husky executa format:check, lint, typecheck - os mesmos scripts do pr-checks.yml (Integração com GitHub Actions).
Template de PR exige evidência de dispositivo: Linhas iOS e Android com PASS, caminhos de teste e build_id do EAS ou link de instalação - não placeholders de "testado localmente".
Auto-label para caminhos de UI e nativos: needs-device-qa em mudanças de src/**, ios/**, android/**; skip-device-qa para PRs apenas de documentação.
Proteção de branch exige quality + evidence: GitHub Actions controla o merge - política vence o sistema de honra; combine com Builds de Preview em PRs para instalações via QR code.
Nunca comite segredos de assinatura: Sem .p8, .jks ou .env com chaves de API - apenas credenciais EAS e Variáveis de Ambiente EAS.
Revise diffs nativos em bumps de SDK: git diff main -- ios/ android/ app.json eas.json antes de mesclar; execute npx expo-doctor no CI em PRs de spike.
Documente o rollback nas mensagens de PR e tag: Plano de canal OTA, feature flag ou branch de hotfix - conecta o histórico Git ao Manual de Rollback e ações de plantão.
Prefira trunk (main) + release/* curtos + hotfix/*. develop de longa duração diverge dos binários da loja e canais OTA em equipes móveis.
main + branches de feature + squash merge + hooks Husky + eas build baseado em tags. Adicione branches de release e evidência de PR quando o QA ou um segundo engenheiro se juntar.
Squash merge no momento do PR é suficiente para a maioria das equipes. Faça rebase em main antes da revisão se quiser um histórico linear; evite fazer rebase após o início da revisão.
Tags acionam pipelines de release; PRs acionam portões de qualidade; a proteção de branch conecta ambos. As escolhas de Git definem o que o CI constrói - veja Melhores Práticas de CI/CD.
Publicar OTA de produção a partir de main enquanto duas versões da loja com valores diferentes de runtimeVersion estão ativas - use lanes de hotfix mapeadas para canais.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026