Mejores prácticas de Git y GitHub
Un resumen condensado de las 25 prácticas más importantes de Git y GitHub para equipos móviles de Expo SDK 57 - extraídas de todas las páginas en esta sección.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 prácticas más importantes de Git y GitHub para equipos móviles de Expo SDK 57 - extraídas de todas las páginas en esta sección.
main es siempre la verdad de integración: Cada PR fusionada debe pasar CI; nunca dejes main roto durante la noche - los pipelines de tienda y OTA asumen un tip verde (Nociones básicas de Git para equipos móviles).
Confirma el lockfile: package-lock.json (o pnpm-lock.yaml) es requerido para npm ci reproducible en Nociones básicas de CI/CD móvil - nunca lo añadas a gitignore.
IDs de ticket en cada commit: feat(checkout): summary sheet [SHIP-412] - los cherry-picks a release/* y hotfix/* dependen de mensajes trazables.
Squash merge de características a main: Un ticket, un commit en la rama de integración - simplifica el cherry-pick a las lanes de release y hotfix.
Ramas de características de corta vida: Objetivo 1-3 días; rebase o merge main diariamente para evitar conflictos en app.json, carpeta native, y eas.json.
Crea release/X.Y antes de congelar: La rama de release contiene el candidato de tienda; las características nuevas aterrizan solo en main hasta que el train se despliegue (Calendario de release train).
Congelación de código es una política de Git: Durante App Review, release/* acepta solo bugfixes - aplica con protección de rama, no recordatorios de Slack.
Cherry-pick - nunca mergea main en release/*: Mergear pull trae características no verificadas en QA al candidato de tienda; elige SHAs explícitos listados en el ticket de release.
Etiqueta desde release/* después de aprobación de QA: v2.6.0 dispara CI de release de EAS; el mensaje de etiqueta incluye build_id verificado en QA (Promoción automatizada de tienda).
Mergea release/* de regreso a main después del rollout: Fast-forward o merge commit preserva el límite del train; elimina la rama de release cuando se completa el rollout al 100%.
Ramas hotfix desde etiquetas: git checkout -b hotfix/2.4.2 v2.4.1 - no desde main o release/2.5.0 - garantiza runtimeVersion correcto y baseline nativo (GitHub Flow y ramas de release).
Lanes de hotfix paralelas por minor en vivo: Cuando 2.4.x y 2.5.0 RC coexisten, separa hotfix/2.4.* y release/2.5.0 - un hotfix abierto por minor a la vez.
Backport cada hotfix: Cherry-pick el SHA de fix a main (si no está ya allí) y a release/* abierto - OTA de producción solo no protege el siguiente binario de tienda.
Mapea ramas de Git a canales de OTA: El canal de producción publica desde hotfix/* o rama de producción documentada - nunca desde feat/* (Canales de release y ramas).
Nunca force-push main, release/*, o hotfix/*: Reescribir historial compartido rompe pistas de auditoría, etiquetas, y linaje de bundle de OTA.
SDK upgrades en spike/* + worktrees: git worktree add mantiene main abierto para características mientras expo upgrade se ejecuta en aislamiento (Rebase interactivo y worktrees).
Rebase interactivo solo en ramas privadas: Squash WIP antes de PR con git rebase -i origin/main; usa --force-with-lease, nunca --force en ramas compartidas.
Puertos de Metro separados por worktree: EXPO_PACKAGER_PORT=8082 en worktree de spike - evita colisiones de packager con trabajo de características diarias.
Pre-commit hooks reflejan CI: Husky ejecuta format:check, lint, typecheck - los mismos scripts que pr-checks.yml (Integración de GitHub Actions).
Plantilla de PR requiere evidencia de dispositivo: Filas iOS y Android con PASS, rutas de prueba, y build_id de EAS o enlace de instalación - no placeholders de "probado localmente".
Auto-label de rutas UI y nativas: needs-device-qa en cambios de src/**, ios/**, android/**; skip-device-qa para PRs de solo docs.
Protección de rama requiere quality + evidence: GitHub Actions controla merge - la política vence al sistema de honor; empareja con Vista previa de builds en PRs para instales de código QR.
Nunca confirmes secretos de firma: Sin .p8, .jks, o .env con claves de API - solo credenciales de EAS y variables de entorno de EAS.
Revisa diffs nativos en SDK bumps: git diff main -- ios/ android/ app.json eas.json antes de mergear; ejecuta npx expo-doctor en CI en PRs de spike.
Documenta rollback en mensajes de PR y etiqueta: Canal de OTA, feature flag, o plan de rama hotfix - vincula el historial de Git a Runbook de rollback y acciones de on-call.
Prefiere trunk (main) + release/* cortos + hotfix/*. develop de larga vida diverge de binarios de tienda y canales de OTA en equipos móviles.
main + ramas de características + squash merge + hooks Husky + eas build impulsado por etiquetas. Añade ramas de release y evidencia de PR cuando QA u otro ingeniero se une.
Squash merge en tiempo de PR es suficiente para la mayoría de equipos. Rebase en main antes de revisión si quieres historial lineal; evita rebase después de que comienza la revisión.
Las etiquetas disparan pipelines de release; los PRs disparan quality gates; la protección de rama conecta ambos. Las decisiones de Git definen qué construye CI - mira Mejores prácticas de CI/CD.
Publicar production OTA desde main mientras dos versiones de tienda con diferentes valores de runtimeVersion están en vivo - usa lanes de hotfix mapeadas a canales.
Versiones de stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0, y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 16 jul 2026