Fundamentos de Git para equipos móviles

Un libro de recetas para un modelo de ramificación que respeta las congelaciones de lanzamiento de tienda - integración basada en troncales en main, ramas de características de corta duración y carriles de lanzamiento que no chocan con las ventanas de revisión de App Store o Play.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

# Trabajo diario de características
git checkout main && git pull --ff-only
git checkout -b feat/SHIP-412-checkout-summary
# ... commits ...
git push -u origin feat/SHIP-412-checkout-summary
# Abre una PR - fusión con squash a main después de revisión + CI verde

# Corte de lanzamiento (martes - antes de congelación del jueves)
git checkout main && git pull --ff-only
git checkout -b release/2.6.0
git push -u origin release/2.6.0
# Solo correcciones cherry-picked o PRs dirigidas a release/2.6.0 hasta tag

# Tag después de la aprobación de QA (post-revisión)
git checkout release/2.6.0
git tag -a v2.6.0 -m "Release 2.6.0 - build_id abc123"
git push origin v2.6.0

Carriles de rama (móvil)
  main              - integración; CI siempre verde
  feat/*            - días, fusión con squash
  release/X.Y       - semanas; congelada durante revisión de tienda
  hotfix/X.Y.Z      - horas; desde tag, cherry-pick a main
  ota/production    - opcional larga vida para solo JS de canal (ver página GitHub Flow)

Cuándo usar esto:

• Primer equipo móvil que adopta Git después de compilaciones ad-hoc en laptops.
• Ventanas de envío a tienda donde fusionar características durante revisión riesga el rechazo.
• Coordinar actualizaciones JavaScript de OTA con binarios de tienda etiquetados.
• Incorporar ingenieros que conocen Git web pero no la disciplina de artefactos nativos.

Cuándo evitarlo:

• Proyecto secundario en solitario sin QA o cadencia de tienda - main + tags puede ser suficiente.
• GitFlow con develop durando meses - la revisión de tienda móvil castiga el desplazamiento.

Ejemplo funcional

End-to-end característica - lanzamiento - congelación - tag para una app Expo SDK 57 que se envía a través de EAS.

Paso 1 - Arrancar higiene del repositorio

npx create-expo-app@latest ShipApp --template blank-typescript
cd ShipApp
git init

# .gitignore - esenciales móviles (NO ignores el lockfile)
node_modules/
.expo/
dist/
*.jks
*.p8
*.p12
*.mobileprovision
ios/Pods/
android/.gradle/
android/app/build/

{
  "scripts": {
    "lint": "expo lint",
    "typecheck": "tsc --noEmit",
    "test": "jest",
    "format:check": "prettier --check .",
    "prepare": "husky"
  }
}

# .husky/pre-commit
npm run format:check && npm run lint && npm run typecheck

• Realiza commit de package-lock.json - CI usa npm ci (Mobile CI/CD Basics)
• Nunca realices commit de claves de firma - EAS almacena credenciales (GitHub Actions + EAS)

Paso 2 - Rama de características con commits con alcance de ticket

git checkout main && git pull --ff-only
git checkout -b feat/SHIP-412-checkout-summary
 
git add src/screens/CheckoutSummary.tsx
git commit -m "feat(checkout): add order summary sheet [SHIP-412]"
 
git push -u origin feat/SHIP-412-checkout-summary

La PR apunta a main. La fusión con squash preserva un commit por característica - cherry-picks más fáciles a release/* después.

Paso 3 - Cortar rama de lanzamiento antes de congelación

<!-- docs/release-calendar.md (fragmento) -->
| Semana | Evento                          | Regla de Git                      |
|--------|-----------------------------------|-----------------------------------|
| W12    | Corte release/2.6.0 Mar 10:00   | Nuevas características - solo main|
| W12    | Congelación de código Jue 18:00 UTC | release/2.6.0: solo correcciones |
| W12    | Envío Vie después Maestro       | Tag v2.6.0 desde rama de lanzamiento |
| W13    | Revisión de tienda en vuelo      | Sin cambios nativos en release/2.6.0 |

git checkout main && git pull --ff-only
git checkout -b release/2.6.0
git push -u origin release/2.6.0

Protección de rama en release/2.6.0:

• Requiere revisiones de PR
• Requiere controles de estado (quality de GitHub Actions Integration)
• Bloquea pushes directos excepto para gestores de lanzamiento

Paso 4 - Cherry-pick una corrección durante congelación

Una corrección crítica llega a main después del corte. Cherry-pick - no fusiones todo de main.

git checkout release/2.6.0 && git pull --ff-only
git cherry-pick <sha-from-main>
git push origin release/2.6.0

# Verifica que el cherry-pick sea la única diferencia vs candidato de tag
git log --oneline main..release/2.6.0
git diff main...release/2.6.0 --stat

Paso 5 - Tag activa pipeline de lanzamiento

git checkout release/2.6.0
git tag -a v2.6.0 -m "Release 2.6.0 - QA build_id abc123"
git push origin v2.6.0

Tag v* activa eas build en CI - mismo artefacto que QA probó (Automated Store Promotion).

Paso 6 - Fusiona rama de lanzamiento de vuelta a main

Después de aprobación de tienda y lanzamiento escalonado:

git checkout main && git pull --ff-only
git merge --ff-only release/2.6.0
git push origin main
git branch -d release/2.6.0
git push origin --delete release/2.6.0

Reglas Git específicas para móvil

# Inspecciona qué cambió en carpetas nativas antes de fusionar bump de SDK
git diff main -- ios/ android/ app.json eas.json
npx expo-doctor

Errores comunes

• Fusión de main en release/* durante revisión - Incorpora características sin QA; riesgo de rechazo de tienda. Solución: Cherry-pick solo SHAs listados.
• Rama de características desde main desactualizado - Rebase antes de PR; conflictos de runtimeVersion desactualizado surgen tarde. Solución: git fetch && git rebase origin/main semanalmente.
• .env realizado commit "solo para CI" - Secretos en Git para siempre. Solución: Variables de entorno de EAS (Environments and EAS Environment Variables).
• Activos binarios en Git sin LFS - Hinchazón del repo ralentiza checkout de CI. Solución: git lfs track "*.psd" u hospeda en CDN.
• Squash merge pierde metadatos de cherry-pick - ID de ticket en cuerpo de commit aún requerido para picks de lanzamiento.

Alternativas

Preguntas frecuentes

Relacionado

• GitHub Flow & Release Branches - carriles hotfix paralelos a canales OTA
• Interactive Rebase & Worktrees - picos de SDK paralelos sin stashing
• GitHub Actions Integration - plantillas de PR y controles requeridos
• Release Train Calendar - ventanas de congelación en calendario compartido
• Mobile CI/CD Basics - qué corre CI en cada rama
• Release Channels & Branches - rama de Git vs rama de EAS Update
• Git & GitHub Best Practices - resumen de 25 elementos

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).