Rebase Interativo e Worktrees

Q: O branch de pico deve mesclar ou fazer rebase no main antes do PR?

git merge origin/main no pico antes do PR é mais seguro para picos longos. O rebase interativo sobre o main produz um histórico linear, mas custa tempo de resolução de conflitos.

Q: O CI pode ser executado em branches de worktree?

Sim - worktrees enviam para o mesmo origin. O branch spike/sdk-57-upgrade aciona as mesmas GitHub Actions que qualquer branch remoto.

Q: Quais commits pertencem a um único squash?

Uma unidade lógica: um ticket ou um bump de SDK. Separe feat de chore(sdk) se os revisores precisarem fazer bisect depois.

Um guia para picos de atualização paralela de SDK usando git worktree e rebase interativo - para que expo upgrade não congele main e sua lista de stash não se torne arqueologia.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# Do clone principal - adicione worktree de pico de SDK (diretório irmão)
cd ~/WEBDEV/ShipApp
git fetch origin
git worktree add ../ShipApp-sdk57-spike -b spike/sdk-57-upgrade origin/main

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

# Clone principal - continue enviando recursos no main
cd ~/WEBDEV/ShipApp
git checkout main
git checkout -b feat/SHIP-501-settings-redesign
# Metro na porta padrão 8081 - o pico usa 8082 (veja abaixo)

# Antes do PR - agrupe commits de correção no branch de recurso
git checkout feat/SHIP-501-settings-redesign
git fetch origin && git rebase -i origin/main
# Marque commits de WIP como squash/fixup; mantenha um commit de recurso

# Após a validação do pico - remova o worktree
cd ~/WEBDEV/ShipApp
git worktree remove ../ShipApp-sdk57-spike

Quando usar isso:

Atualização do SDK do Expo que se estende por dias enquanto os recursos precisam ser mesclados em main.
Diferença de prebuild nativo que você precisa comparar lado a lado com o branch de produção.
Pico de longa duração (nova biblioteca de navegação) sem bloquear o npm ci dos colegas de equipe.
Limpeza de PR - dez commits "fix lint" devem ser um commit antes da revisão.

Quando evitar:

Branches compartilhados release/* ou hotfix/* que outros já verificaram - rebase reescreve o histórico.
Branch já enviado no qual outros baseiam o trabalho - coordene ou mescle em vez de rebase.
Laptop com restrição de disco - duas árvores completas de node_modules custam gigabytes.

Exemplo de Trabalho

Cenário: ShipApp executa o Expo SDK 56 em produção. A equipe precisa do pico do SDK 57 enquanto os branches feat/* chegam diariamente no main.

Passo 1 - Criar 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 os diretórios compartilham um único armazenamento de objetos .git - os branches diferem, os discos são separados.

Passo 2 - Isolar portas do Metro

# ../ShipApp-sdk57-spike/.env.local (ignorado pelo git)
EXPO_PACKAGER_PORT=8082

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

O clone principal mantém npx expo start na porta 8081 - sem colisões de "porta já em uso".

Passo 3 - Executar atualização com commits de checkpoint

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
# corrigir quebras...
git commit -am "fix(types): navigation params after RN 0.86 [SPIKE-57]"

Commits de WIP são aceitáveis no branch de pico - rebase interativo antes de abrir o PR.

Passo 4 - Trabalho de recurso paralelo no clone principal

cd ~/WEBDEV/ShipApp
git checkout -b feat/SHIP-501-settings-redesign
# não afetado pelo package.json do pico - node_modules separadas
npm ci
npm run test -- --ci
git push -u origin feat/SHIP-501-settings-redesign

Colegas de equipe nunca puxam um SDK meio atualizado do main.

Passo 5 - Rebase interativo antes do PR

O branch de recurso acumulou ruído:

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

No editor, reordene e marque:

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 - mais seguro que --force; falha se o remoto avançou
Reescreva apenas seus branches de recurso - nunca main, release/*, hotfix/*

Passo 6 - Concluir pico e pousar no main

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

Agrupe os commits do pico para revisão:

git rebase -i origin/main
# agrupe todos os commits SPIKE-57 em um:
# chore(sdk): upgrade to Expo SDK 57 [SPIKE-57]

git push -u origin spike/sdk-57-upgrade
# Abra PR → main; matriz de dispositivos completa + build de pré-visualização EAS são necessários

Após a mesclagem:

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

Acione build de pré-visualização no PR para PRs de SDK - o Expo Go sozinho perde as alterações nativas.

Matriz de Segurança de Rebase

Tipo de branch	Rebase interativo?	Push forçado?
`feat/*` (individual)	Sim	`--force-with-lease` OK
`spike/*`	Sim	`--force-with-lease` OK
`main`	Não	Nunca
`release/*`	Não	Quebra a auditoria de RC
`hotfix/*`	Não	Use cherry-pick em vez disso
`feat/*` compartilhado	Coordenar	Prefira mesclar

# Abortar um rebase que deu errado
git rebase --abort
 
# Reflog de recuperação
git reflog | head -20
git checkout -b recovery-branch HEAD@{3}

Referência de Comandos Worktree

git worktree list
git worktree add ../path -b new-branch start-point
git worktree remove ../path
git worktree prune   # limpa metadados obsoletos
 
# Não é possível remover worktree com alterações não commitadas
git -C ../ShipApp-sdk57-spike status

# Opcional: node_modules compartilhadas via pnpm (avançado)
# Prefira npm ci completo por worktree para fidelidade com CI

Armadilhas

Um branch verificado em dois worktrees - Git proíbe isso. Correção: Branch diferente por diretório de worktree.
Rebase após o início da revisão do PR - Invalida comentários de revisão em SHAs antigos. Correção: Faça rebase antes de solicitar a revisão ou mescle main em vez disso.
Picos mesclados sem expo-doctor em CI - Desalinhamento oculto de dependências. Correção: Adicione uma etapa do doctor às verificações de PR.
Worktree esquecido consome disco - git worktree list mensalmente. Correção: git worktree remove + git worktree prune.
Rebase interativo em commits de merge - Conflitos confusos. Correção: git rebase -i --rebase-merges ou evite commits de merge em branches de recurso.

Alternativas

Alternativa	Use Quando	Não Use Quando
`git stash`	Troca de contexto de 30 minutos	Pico de SDK de vários dias
Segundo clone completo	Modelo mental simples	Dobra o tempo de busca e o disco
Feature flags no main	Pequena diferença de SDK	Reforma completa da pasta nativa
PR Draft do pico	Visibilidade sem mesclagem	Ainda bloqueia CI se mirar no main cedo

Worktrees compartilham o banco de dados de objetos - mais rápido, menos disco. O segundo clone é mais simples, mas duplica o histórico .git. Prefira worktrees para branches paralelos do mesmo repositório.

Quantos worktrees são práticos?

Dois ou três (main + spike + investigação de hotfix). Mais do que isso - o disco e a sobrecarga mental excedem o benefício.

O branch de pico deve mesclar ou fazer rebase no main antes do PR?

git merge origin/main no pico antes do PR é mais seguro para picos longos. O rebase interativo sobre o main produz um histórico linear, mas custa tempo de resolução de conflitos.

O CI pode ser executado em branches de worktree?

Sim - worktrees enviam para o mesmo origin. O branch spike/sdk-57-upgrade aciona as mesmas GitHub Actions que qualquer branch remoto.

Quais commits pertencem a um único squash?

Uma unidade lógica: um ticket ou um bump de SDK. Separe feat de chore(sdk) se os revisores precisarem fazer bisect depois.

Relacionados

Fundamentos de Git para Equipes Mobile - quando não tocar em branches de lançamento
Fluxo do GitHub e Branches de Lançamento - lanes de hotfix evitam rebase
Integração com GitHub Actions - PR de SDK requer evidência de build de pré-visualização
Builds de Pré-visualização em PRs - validação nativa para atualizações de SDK
Fluxos de Trabalho EAS - expo-doctor antes de type: build
Fundamentos de CI/CD Mobile - verificações de PR que os branches de pico usam
Melhores Práticas de Git e GitHub - Resumo de 25 itens

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

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# Do clone principal - adicione worktree de pico de SDK (diretório irmão)
cd ~/WEBDEV/ShipApp
git fetch origin
git worktree add ../ShipApp-sdk57-spike -b spike/sdk-57-upgrade origin/main

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

# Clone principal - continue enviando recursos no main
cd ~/WEBDEV/ShipApp
git checkout main
git checkout -b feat/SHIP-501-settings-redesign
# Metro na porta padrão 8081 - o pico usa 8082 (veja abaixo)

# Antes do PR - agrupe commits de correção no branch de recurso
git checkout feat/SHIP-501-settings-redesign
git fetch origin && git rebase -i origin/main
# Marque commits de WIP como squash/fixup; mantenha um commit de recurso

# Após a validação do pico - remova o worktree
cd ~/WEBDEV/ShipApp
git worktree remove ../ShipApp-sdk57-spike

Quando usar isso:

Atualização do SDK do Expo que se estende por dias enquanto os recursos precisam ser mesclados em main.
Diferença de prebuild nativo que você precisa comparar lado a lado com o branch de produção.
Pico de longa duração (nova biblioteca de navegação) sem bloquear o npm ci dos colegas de equipe.
Limpeza de PR - dez commits "fix lint" devem ser um commit antes da revisão.

Quando evitar:

Branches compartilhados release/* ou hotfix/* que outros já verificaram - rebase reescreve o histórico.
Branch já enviado no qual outros baseiam o trabalho - coordene ou mescle em vez de rebase.
Laptop com restrição de disco - duas árvores completas de node_modules custam gigabytes.

Exemplo de Trabalho

Cenário: ShipApp executa o Expo SDK 56 em produção. A equipe precisa do pico do SDK 57 enquanto os branches feat/* chegam diariamente no main.

Passo 1 - Criar 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 os diretórios compartilham um único armazenamento de objetos .git - os branches diferem, os discos são separados.

Passo 2 - Isolar portas do Metro

# ../ShipApp-sdk57-spike/.env.local (ignorado pelo git)
EXPO_PACKAGER_PORT=8082

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

O clone principal mantém npx expo start na porta 8081 - sem colisões de "porta já em uso".

Passo 3 - Executar atualização com commits de checkpoint

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
# corrigir quebras...
git commit -am "fix(types): navigation params after RN 0.86 [SPIKE-57]"

Commits de WIP são aceitáveis no branch de pico - rebase interativo antes de abrir o PR.

Passo 4 - Trabalho de recurso paralelo no clone principal

cd ~/WEBDEV/ShipApp
git checkout -b feat/SHIP-501-settings-redesign
# não afetado pelo package.json do pico - node_modules separadas
npm ci
npm run test -- --ci
git push -u origin feat/SHIP-501-settings-redesign

Colegas de equipe nunca puxam um SDK meio atualizado do main.

Passo 5 - Rebase interativo antes do PR

O branch de recurso acumulou ruído:

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

No editor, reordene e marque:

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 - mais seguro que --force; falha se o remoto avançou
Reescreva apenas seus branches de recurso - nunca main, release/*, hotfix/*

Passo 6 - Concluir pico e pousar no main

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

Agrupe os commits do pico para revisão:

git rebase -i origin/main
# agrupe todos os commits SPIKE-57 em um:
# chore(sdk): upgrade to Expo SDK 57 [SPIKE-57]

git push -u origin spike/sdk-57-upgrade
# Abra PR → main; matriz de dispositivos completa + build de pré-visualização EAS são necessários

Após a mesclagem:

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

Acione build de pré-visualização no PR para PRs de SDK - o Expo Go sozinho perde as alterações nativas.

Matriz de Segurança de Rebase

Tipo de branch	Rebase interativo?	Push forçado?
`feat/*` (individual)	Sim	`--force-with-lease` OK
`spike/*`	Sim	`--force-with-lease` OK
`main`	Não	Nunca
`release/*`	Não	Quebra a auditoria de RC
`hotfix/*`	Não	Use cherry-pick em vez disso
`feat/*` compartilhado	Coordenar	Prefira mesclar

# Abortar um rebase que deu errado
git rebase --abort
 
# Reflog de recuperação
git reflog | head -20
git checkout -b recovery-branch HEAD@{3}

Referência de Comandos Worktree

git worktree list
git worktree add ../path -b new-branch start-point
git worktree remove ../path
git worktree prune   # limpa metadados obsoletos
 
# Não é possível remover worktree com alterações não commitadas
git -C ../ShipApp-sdk57-spike status

# Opcional: node_modules compartilhadas via pnpm (avançado)
# Prefira npm ci completo por worktree para fidelidade com CI

Armadilhas

Um branch verificado em dois worktrees - Git proíbe isso. Correção: Branch diferente por diretório de worktree.
Rebase após o início da revisão do PR - Invalida comentários de revisão em SHAs antigos. Correção: Faça rebase antes de solicitar a revisão ou mescle main em vez disso.
Picos mesclados sem expo-doctor em CI - Desalinhamento oculto de dependências. Correção: Adicione uma etapa do doctor às verificações de PR.
Worktree esquecido consome disco - git worktree list mensalmente. Correção: git worktree remove + git worktree prune.
Rebase interativo em commits de merge - Conflitos confusos. Correção: git rebase -i --rebase-merges ou evite commits de merge em branches de recurso.

Alternativas

Alternativa	Use Quando	Não Use Quando
`git stash`	Troca de contexto de 30 minutos	Pico de SDK de vários dias
Segundo clone completo	Modelo mental simples	Dobra o tempo de busca e o disco
Feature flags no main	Pequena diferença de SDK	Reforma completa da pasta nativa
PR Draft do pico	Visibilidade sem mesclagem	Ainda bloqueia CI se mirar no main cedo

FAQs

worktree vs segundo clone git?

Quantos worktrees são práticos?

Dois ou três (main + spike + investigação de hotfix). Mais do que isso - o disco e a sobrecarga mental excedem o benefício.

O branch de pico deve mesclar ou fazer rebase no main antes do PR?

git merge origin/main no pico antes do PR é mais seguro para picos longos. O rebase interativo sobre o main produz um histórico linear, mas custa tempo de resolução de conflitos.

O CI pode ser executado em branches de worktree?

Sim - worktrees enviam para o mesmo origin. O branch spike/sdk-57-upgrade aciona as mesmas GitHub Actions que qualquer branch remoto.

Quais commits pertencem a um único squash?

Uma unidade lógica: um ticket ou um bump de SDK. Separe feat de chore(sdk) se os revisores precisarem fazer bisect depois.

Relacionados

Fundamentos de Git para Equipes Mobile - quando não tocar em branches de lançamento
Fluxo do GitHub e Branches de Lançamento - lanes de hotfix evitam rebase
Integração com GitHub Actions - PR de SDK requer evidência de build de pré-visualização
Builds de Pré-visualização em PRs - validação nativa para atualizações de SDK
Fluxos de Trabalho EAS - expo-doctor antes de type: build
Fundamentos de CI/CD Mobile - verificações de PR que os branches de pico usam
Melhores Práticas de Git e GitHub - Resumo de 25 itens

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

Rebase Interativo e Worktrees

Buscar na documentação

Rebase Interativo e Worktrees