Technieken om rebasen minder pijnlijk te maken

Ik zie vaak ontwikkelaars main in hun feature branches mergen en pull requests (PR’s) openen met commits van andere branches. Dat leidt tot “git-spaghetti”, met een paar gevolgen:

• Het maakt de commitgeschiedenis ingewikkelder
• Het vergroot het risico op conflicten die anderen moeilijk kunnen oplossen
• Het kan wijzigingen binnenhalen die nog niet klaar zijn voor main
• Het hindert de code review, omdat overbodige wijzigingen afleiden van het eigenlijke doel van de PR

Soft reset vóór het rebasen

Gebruik git reset om terug te spoelen naar het punt waar je branch van de main branch afsplitste. Je wijzigingen blijven intact in je werkmap, klaar om op een schonere, nettere manier te worden gecommit.

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

Voordelen:

• Je wijzigingen blijven in je werkmap
• Het rebasen wordt simpeler omdat je minder commits hoeft te beheren
• Je krijgt een schonere, zinvollere commitgeschiedenis
• Minder druk om een commitbericht te verzinnen, want je squasht ze gewoon tot één

Fetch in plaats van pull

Draai git fetch om je repository bij te werken met de laatste wijzigingen van de remote, zonder die automatisch in je lokale branch te mergen. Zo kun je de wijzigingen bekijken voordat je beslist hoe je ze verwerkt.

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

Voordelen:

• Jij bepaalt wanneer je nieuwe wijzigingen van je team binnenhaalt
• Je begrijpt nieuwe commits beter voordat je ze merget of rebaset
• Je houdt makkelijker een lineaire, schone commitgeschiedenis