← Todos os textos

Técnicas para tornar o rebase menos dor de cabeça

Nesta página

Vejo muitas vezes programadores a fazer merge do main para os seus ramos de funcionalidade e a abrir pull requests (PRs) que incluem commits de outros ramos. Esta prática dá “esparguete de git”, com várias consequências:

  • Complica o histórico de commits
  • Aumenta o risco de conflitos que são difíceis de resolver por outros
  • Pode introduzir alterações que não estão prontas para o main
  • Atrapalha a revisão de código, porque alterações alheias distraem do propósito central do PR

Soft reset antes do rebase

Usa o git reset para recuar até ao ponto em que o teu ramo se separou do ramo principal. Isto mantém as tuas alterações intactas no diretório de trabalho, prontas para serem submetidas de forma mais limpa e organizada.

git reflog  # Identify the divergence point
git reset commit_sha  # Soft reset to this point

Vantagens:

  • Mantém as tuas alterações no diretório de trabalho
  • Simplifica o rebase, porque reduz o número de commits a gerir
  • Dá um histórico de commits mais limpo e com mais sentido
  • Menos pressão para decidir a mensagem do commit, porque juntas tudo num só com squash

Fetch em vez de pull

Corre o git fetch para atualizar o teu repositório com as últimas alterações do remoto sem as juntar automaticamente ao teu ramo local. Isto dá-te a hipótese de rever as alterações antes de decidires como as integrar.

git fetch origin
git rebase origin/main  # Rebase your branch on the updated main branch

Vantagens:

  • Deixa-te decidir quando incorporar as alterações novas da tua equipa
  • Melhora a compreensão dos commits novos antes do merge ou do rebase
  • Ajuda a manter um histórico de commits linear e limpo