Des techniques pour que le rebase soit moins pénible

Je vois souvent des développeurs merger main dans leurs branches de fonctionnalité et ouvrir des pull requests (PR) qui incluent des commits venus d’autres branches. Cette pratique produit des « spaghettis git », avec plusieurs conséquences :

• Ça complique l’historique des commits
• Ça augmente le risque de conflits que les autres auront du mal à résoudre
• Ça peut introduire des changements qui ne sont pas prêts pour main
• Ça gêne la relecture, parce que des changements parasites détournent l’attention de l’objet réel de la PR

Un reset soft avant de rebaser

Utilise git reset pour revenir au point où ta branche a divergé de la branche principale. Tes changements restent intacts dans le répertoire de travail, prêts à être commités de façon plus propre et mieux organisée.

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

Avantages :

• Garde tes changements dans le répertoire de travail
• Simplifie le rebase en réduisant le nombre de commits à gérer
• Donne un historique de commits plus propre et plus parlant
• Moins de pression pour choisir un message de commit, puisque tu les écrases en un seul

Fetch plutôt que pull

Lance git fetch pour mettre à jour ton dépôt avec les derniers changements du distant, sans les fusionner automatiquement dans ta branche locale. Tu as ainsi la possibilité de relire les changements avant de décider comment les intégrer.

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

Avantages :

• Tu décides quand incorporer les nouveaux changements de ton équipe
• Tu comprends mieux les nouveaux commits avant de merger ou de rebaser
• Ça aide à garder un historique de commits linéaire et propre