Rebase Interactivo y Worktrees

Q: ¿Debe la rama spike fusionarse o hacer rebase en main antes de PR?

git merge origin/main en spike antes de PR es más seguro para picos largos. Interactive rebase onto main produce historial lineal pero cuesta tiempo de resolución de conflictos.

Q: ¿Puede CI ejecutarse en ramas de worktree?

Sí - los worktrees se envían al mismo origin. La rama spike/sdk-57-upgrade desencadena las mismas Acciones de GitHub que cualquier rama remota.

Q: ¿Qué commits pertenecen a un squash?

Una unidad lógica: un ticket o un bump de SDK. Separa feat de chore(sdk) si los revisores necesitan bisectar más tarde.

Un manual para picos de actualización de SDK en paralelo usando git worktree y interactive rebase - para que expo upgrade no congele main y tu lista de stash no se convierta en arqueología.

Receta

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

# Desde el clon principal - agregar worktree de pico de SDK (directorio hermano)
cd ~/WEBDEV/ShipApp
git fetch origin
git worktree add ../ShipApp-sdk57-spike -b spike/sdk-57-upgrade origin/main

# Worktree de pico - actualizar en aislamiento
cd ../ShipApp-sdk57-spike
npm ci
npx expo install expo@~57.0.4 --fix
npx expo-doctor
npm run typecheck && npm run test -- --ci

# Clon principal - seguir entregando características en main
cd ~/WEBDEV/ShipApp
git checkout main
git checkout -b feat/SHIP-501-settings-redesign
# Metro en puerto 8081 predeterminado - el pico usa 8082 (ver abajo)

# Antes de PR - comprimir commits fixup en rama de características
git checkout feat/SHIP-501-settings-redesign
git fetch origin && git rebase -i origin/main
# Marcar commits WIP como squash/fixup; mantener un commit de feat

# Después de validar el pico - eliminar worktree
cd ~/WEBDEV/ShipApp
git worktree remove ../ShipApp-sdk57-spike

Cuándo usar esto:

Actualización de Expo SDK que abarca días mientras las características deben fusionarse en main.
Diff de prebuild nativo que necesitas comparar lado a lado con la rama de producción.
Pico de larga duración (nueva biblioteca de navegación) sin bloquear npm ci de los compañeros de equipo.
Limpieza de PR - diez commits de "fix lint" deben ser un commit antes de la revisión.

Cuándo evitar:

Ramas compartidas release/* o hotfix/* que otros han extraído - rebase reescribe el historial.
Rama ya enviada en la que otros basaron trabajo - coordina o fusiona en lugar de hacer rebase.
Portátil con espacio limitado - dos árboles completos de node_modules cuestan gigabytes.

Ejemplo de Trabajo

Escenario: ShipApp ejecuta Expo SDK 56 en producción. El equipo necesita un pico de SDK 57 mientras que ramas feat/* se fusionan diariamente en main.

Paso 1 - Crear worktree de pico

cd ~/WEBDEV/ShipApp
git pull --ff-only origin main
git worktree add ../ShipApp-sdk57-spike -b spike/sdk-57-upgrade origin/main
git worktree list

/Users/csjcode/WEBDEV/ShipApp              abc1234 [main]
/Users/csjcode/WEBDEV/ShipApp-sdk57-spike  abc1234 [spike/sdk-57-upgrade]

Ambos directorios comparten un almacén de objetos .git - las ramas difieren, los discos se separan.

Paso 2 - Aislar puertos de Metro

# ../ShipApp-sdk57-spike/.env.local (gitignored)
EXPO_PACKAGER_PORT=8082

cd ../ShipApp-sdk57-spike
npm ci
npx expo start --port 8082

El clon principal mantiene npx expo start en el puerto 8081 - sin colisiones de "puerto ya en uso".

Paso 3 - Ejecutar actualización con commits de punto de control

cd ../ShipApp-sdk57-spike
 
npx expo install expo@~57.0.4 --fix
git add package.json package-lock.json
git commit -m "chore(sdk): bump expo to SDK 57 [SPIKE-57]"
 
npx expo prebuild --clean
git add ios android
git commit -m "chore(native): prebuild after SDK 57 [SPIKE-57]"
 
npm run typecheck
# arreglar fallos...
git commit -am "fix(types): navigation params after RN 0.86 [SPIKE-57]"

Los commits WIP están bien en rama de pico - interactive rebase antes de abrir PR.

Paso 4 - Trabajo de característica en paralelo en el clon principal

cd ~/WEBDEV/ShipApp
git checkout -b feat/SHIP-501-settings-redesign
# no afectado por el package.json del pico - node_modules separados
npm ci
npm run test -- --ci
git push -u origin feat/SHIP-501-settings-redesign

Los compañeros de equipo nunca extraen SDK medio actualizado de main.

Paso 5 - Interactive rebase antes de PR

La rama de características acumuló ruido:

git checkout feat/SHIP-501-settings-redesign
git log --oneline origin/main..HEAD

a1b2c3d fix typo
d4e5f6g fix lint
g7h8i9j feat(settings): redesign layout [SHIP-501]
j1k2l3m wip

git rebase -i origin/main

En el editor, reordena y marca:

pick g7h8i9j feat(settings): redesign layout [SHIP-501]
squash j1k2l3m wip
squash d4e5f6g fix lint
squash a1b2c3d fix typo

git push --force-with-lease origin feat/SHIP-501-settings-redesign

--force-with-lease - más seguro que --force; falla si remoto avanzó
Solo reescribe tus ramas de características - nunca main, release/*, hotfix/*

Paso 6 - Terminar pico e integrar en main

cd ../ShipApp-sdk57-spike
npm run lint && npm run typecheck && npm run test -- --ci
npx expo-doctor

Comprimir commits de pico para revisión:

git rebase -i origin/main
# comprimir todos los commits SPIKE-57 en uno:
# chore(sdk): upgrade to Expo SDK 57 [SPIKE-57]

git push -u origin spike/sdk-57-upgrade
# Abrir PR hacia main; matriz completa de dispositivos + compilación de vista previa de EAS requerida

Después de la fusión:

cd ~/WEBDEV/ShipApp
git pull --ff-only origin main
git worktree remove ../ShipApp-sdk57-spike
git branch -d spike/sdk-57-upgrade   # si se fusionó

Desencadenar compilación de vista previa en PR para PRs de SDK - solo Expo Go pierde cambios nativos.

Matriz de Seguridad de Rebase

Tipo de rama	¿Interactive rebase?	¿Force push?
`feat/*` (solo)	Sí	`--force-with-lease` OK
`spike/*`	Sí	`--force-with-lease` OK
`main`	No	Nunca
`release/*`	No	Rompe auditoría de RC
`hotfix/*`	No	Cherry-pick en su lugar
`feat/*` compartido	Coordina	Prefiere fusión

# Abortar un rebase que salió mal
git rebase --abort
 
# Recuperación de reflog
git reflog | head -20
git checkout -b recovery-branch HEAD@{3}

Referencia de Comandos de Worktree

git worktree list
git worktree add ../path -b new-branch start-point
git worktree remove ../path
git worktree prune   # limpiar metadatos obsoletos
 
# No se puede eliminar worktree con cambios sin confirmar
git -C ../ShipApp-sdk57-spike status

# Opcional: node_modules compartido a través de pnpm (avanzado)
# Prefiere npm ci completo por worktree para fidelidad con CI

Errores Comunes

Una rama extraída en dos worktrees - Git lo prohíbe. Arreglo: Rama diferente por directorio de worktree.
Hacer rebase después de que comenzó la revisión de PR - Invalida comentarios de revisión en SHAs antiguos. Arreglo: Rebase antes de solicitar revisión, o fusiona main en su lugar.
El pico se fusiona sin expo-doctor en CI - Sesgo de dependencia oculto. Arreglo: Agregar paso de doctor a verificaciones de PR.
Worktree olvidado consume disco - git worktree list mensualmente. Arreglo: git worktree remove + git worktree prune.
Interactive rebase en commits de fusión - Conflictos confusos. Arreglo: git rebase -i --rebase-merges o evita commits de fusión en ramas de características.

Alternativas

Alternativa	Usar cuándo	No usar cuándo
`git stash`	Cambio de contexto de 30 minutos	Pico de SDK de múltiples días
Clon completo segunda	Modelo mental simple	Doble tiempo de fetch y disco
Banderas de características en main	Delta de SDK pequeño	Revisión de carpeta nativa
PR de borrador desde pico	Visibilidad sin fusión	Aún bloquea CI si se dirige a main temprano

Preguntas Frecuentes

¿worktree vs segundo clon de git?

Worktrees comparten base de datos de objetos - más rápido, menos disco. El segundo clon es más simple pero duplica historial de .git. Prefiere worktrees para ramas paralelas del mismo repositorio.

¿Cuántos worktrees son prácticos?

Dos o tres (main + spike + investigación de hotfix). Más que eso - el disco y la sobrecarga mental superan el beneficio.

¿Debe la rama spike fusionarse o hacer rebase en main antes de PR?

git merge origin/main en spike antes de PR es más seguro para picos largos. Interactive rebase onto main produce historial lineal pero cuesta tiempo de resolución de conflictos.

¿Puede CI ejecutarse en ramas de worktree?

Sí - los worktrees se envían al mismo origin. La rama spike/sdk-57-upgrade desencadena las mismas Acciones de GitHub que cualquier rama remota.

¿Qué commits pertenecen a un squash?

Una unidad lógica: un ticket o un bump de SDK. Separa feat de chore(sdk) si los revisores necesitan bisectar más tarde.

Relacionado

Git Basics for Mobile Teams - cuándo no tocar ramas de lanzamiento
GitHub Flow & Release Branches - carriles de hotfix evitan rebase
GitHub Actions Integration - PR de SDK requiere evidencia de compilación de vista previa
Preview Builds on PRs - validación nativa para actualizaciones de SDK
EAS Workflows - expo-doctor antes de type: build
Mobile CI/CD Basics - verificaciones de PR que usan ramas de pico
Git & GitHub Best Practices - resumen de 25 elementos

Versiones de pila: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).

Receta

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

# Desde el clon principal - agregar worktree de pico de SDK (directorio hermano)
cd ~/WEBDEV/ShipApp
git fetch origin
git worktree add ../ShipApp-sdk57-spike -b spike/sdk-57-upgrade origin/main

# Worktree de pico - actualizar en aislamiento
cd ../ShipApp-sdk57-spike
npm ci
npx expo install expo@~57.0.4 --fix
npx expo-doctor
npm run typecheck && npm run test -- --ci

# Clon principal - seguir entregando características en main
cd ~/WEBDEV/ShipApp
git checkout main
git checkout -b feat/SHIP-501-settings-redesign
# Metro en puerto 8081 predeterminado - el pico usa 8082 (ver abajo)

# Antes de PR - comprimir commits fixup en rama de características
git checkout feat/SHIP-501-settings-redesign
git fetch origin && git rebase -i origin/main
# Marcar commits WIP como squash/fixup; mantener un commit de feat

# Después de validar el pico - eliminar worktree
cd ~/WEBDEV/ShipApp
git worktree remove ../ShipApp-sdk57-spike

Cuándo usar esto:

Actualización de Expo SDK que abarca días mientras las características deben fusionarse en main.
Diff de prebuild nativo que necesitas comparar lado a lado con la rama de producción.
Pico de larga duración (nueva biblioteca de navegación) sin bloquear npm ci de los compañeros de equipo.
Limpieza de PR - diez commits de "fix lint" deben ser un commit antes de la revisión.

Cuándo evitar:

Ramas compartidas release/* o hotfix/* que otros han extraído - rebase reescribe el historial.
Rama ya enviada en la que otros basaron trabajo - coordina o fusiona en lugar de hacer rebase.
Portátil con espacio limitado - dos árboles completos de node_modules cuestan gigabytes.

Ejemplo de Trabajo

Escenario: ShipApp ejecuta Expo SDK 56 en producción. El equipo necesita un pico de SDK 57 mientras que ramas feat/* se fusionan diariamente en main.

Paso 1 - Crear worktree de pico

cd ~/WEBDEV/ShipApp
git pull --ff-only origin main
git worktree add ../ShipApp-sdk57-spike -b spike/sdk-57-upgrade origin/main
git worktree list

/Users/csjcode/WEBDEV/ShipApp              abc1234 [main]
/Users/csjcode/WEBDEV/ShipApp-sdk57-spike  abc1234 [spike/sdk-57-upgrade]

Ambos directorios comparten un almacén de objetos .git - las ramas difieren, los discos se separan.

Paso 2 - Aislar puertos de Metro

# ../ShipApp-sdk57-spike/.env.local (gitignored)
EXPO_PACKAGER_PORT=8082

cd ../ShipApp-sdk57-spike
npm ci
npx expo start --port 8082

El clon principal mantiene npx expo start en el puerto 8081 - sin colisiones de "puerto ya en uso".

Paso 3 - Ejecutar actualización con commits de punto de control

cd ../ShipApp-sdk57-spike
 
npx expo install expo@~57.0.4 --fix
git add package.json package-lock.json
git commit -m "chore(sdk): bump expo to SDK 57 [SPIKE-57]"
 
npx expo prebuild --clean
git add ios android
git commit -m "chore(native): prebuild after SDK 57 [SPIKE-57]"
 
npm run typecheck
# arreglar fallos...
git commit -am "fix(types): navigation params after RN 0.86 [SPIKE-57]"

Los commits WIP están bien en rama de pico - interactive rebase antes de abrir PR.

Paso 4 - Trabajo de característica en paralelo en el clon principal

cd ~/WEBDEV/ShipApp
git checkout -b feat/SHIP-501-settings-redesign
# no afectado por el package.json del pico - node_modules separados
npm ci
npm run test -- --ci
git push -u origin feat/SHIP-501-settings-redesign

Los compañeros de equipo nunca extraen SDK medio actualizado de main.

Paso 5 - Interactive rebase antes de PR

La rama de características acumuló ruido:

git checkout feat/SHIP-501-settings-redesign
git log --oneline origin/main..HEAD

a1b2c3d fix typo
d4e5f6g fix lint
g7h8i9j feat(settings): redesign layout [SHIP-501]
j1k2l3m wip

git rebase -i origin/main

En el editor, reordena y marca:

pick g7h8i9j feat(settings): redesign layout [SHIP-501]
squash j1k2l3m wip
squash d4e5f6g fix lint
squash a1b2c3d fix typo

git push --force-with-lease origin feat/SHIP-501-settings-redesign

--force-with-lease - más seguro que --force; falla si remoto avanzó
Solo reescribe tus ramas de características - nunca main, release/*, hotfix/*

Paso 6 - Terminar pico e integrar en main

cd ../ShipApp-sdk57-spike
npm run lint && npm run typecheck && npm run test -- --ci
npx expo-doctor

Comprimir commits de pico para revisión:

git rebase -i origin/main
# comprimir todos los commits SPIKE-57 en uno:
# chore(sdk): upgrade to Expo SDK 57 [SPIKE-57]

git push -u origin spike/sdk-57-upgrade
# Abrir PR hacia main; matriz completa de dispositivos + compilación de vista previa de EAS requerida

Después de la fusión:

cd ~/WEBDEV/ShipApp
git pull --ff-only origin main
git worktree remove ../ShipApp-sdk57-spike
git branch -d spike/sdk-57-upgrade   # si se fusionó

Desencadenar compilación de vista previa en PR para PRs de SDK - solo Expo Go pierde cambios nativos.

Matriz de Seguridad de Rebase

Tipo de rama	¿Interactive rebase?	¿Force push?
`feat/*` (solo)	Sí	`--force-with-lease` OK
`spike/*`	Sí	`--force-with-lease` OK
`main`	No	Nunca
`release/*`	No	Rompe auditoría de RC
`hotfix/*`	No	Cherry-pick en su lugar
`feat/*` compartido	Coordina	Prefiere fusión

# Abortar un rebase que salió mal
git rebase --abort
 
# Recuperación de reflog
git reflog | head -20
git checkout -b recovery-branch HEAD@{3}

Referencia de Comandos de Worktree

git worktree list
git worktree add ../path -b new-branch start-point
git worktree remove ../path
git worktree prune   # limpiar metadatos obsoletos
 
# No se puede eliminar worktree con cambios sin confirmar
git -C ../ShipApp-sdk57-spike status

# Opcional: node_modules compartido a través de pnpm (avanzado)
# Prefiere npm ci completo por worktree para fidelidad con CI

Errores Comunes

Una rama extraída en dos worktrees - Git lo prohíbe. Arreglo: Rama diferente por directorio de worktree.
Hacer rebase después de que comenzó la revisión de PR - Invalida comentarios de revisión en SHAs antiguos. Arreglo: Rebase antes de solicitar revisión, o fusiona main en su lugar.
El pico se fusiona sin expo-doctor en CI - Sesgo de dependencia oculto. Arreglo: Agregar paso de doctor a verificaciones de PR.
Worktree olvidado consume disco - git worktree list mensualmente. Arreglo: git worktree remove + git worktree prune.
Interactive rebase en commits de fusión - Conflictos confusos. Arreglo: git rebase -i --rebase-merges o evita commits de fusión en ramas de características.

Alternativas

Alternativa	Usar cuándo	No usar cuándo
`git stash`	Cambio de contexto de 30 minutos	Pico de SDK de múltiples días
Clon completo segunda	Modelo mental simple	Doble tiempo de fetch y disco
Banderas de características en main	Delta de SDK pequeño	Revisión de carpeta nativa
PR de borrador desde pico	Visibilidad sin fusión	Aún bloquea CI si se dirige a main temprano

Preguntas Frecuentes

¿worktree vs segundo clon de git?

¿Cuántos worktrees son prácticos?

Dos o tres (main + spike + investigación de hotfix). Más que eso - el disco y la sobrecarga mental superan el beneficio.

¿Debe la rama spike fusionarse o hacer rebase en main antes de PR?

git merge origin/main en spike antes de PR es más seguro para picos largos. Interactive rebase onto main produce historial lineal pero cuesta tiempo de resolución de conflictos.

¿Puede CI ejecutarse en ramas de worktree?

Sí - los worktrees se envían al mismo origin. La rama spike/sdk-57-upgrade desencadena las mismas Acciones de GitHub que cualquier rama remota.

¿Qué commits pertenecen a un squash?

Una unidad lógica: un ticket o un bump de SDK. Separa feat de chore(sdk) si los revisores necesitan bisectar más tarde.

Relacionado

Git Basics for Mobile Teams - cuándo no tocar ramas de lanzamiento
GitHub Flow & Release Branches - carriles de hotfix evitan rebase
GitHub Actions Integration - PR de SDK requiere evidencia de compilación de vista previa
Preview Builds on PRs - validación nativa para actualizaciones de SDK
EAS Workflows - expo-doctor antes de type: build
Mobile CI/CD Basics - verificaciones de PR que usan ramas de pico
Git & GitHub Best Practices - resumen de 25 elementos

Versiones de pila: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).

Rebase Interactivo y Worktrees

Buscar en la documentación

Rebase Interactivo y Worktrees