Rebase oder Merge: einen Branch integrieren

Worum es geht

git merge verbindet zwei Entwicklungslinien mit einem Merge-Commit, der zwei Eltern hat; die Historie zeigt, wann der Branch abzweigte und wann er zurückgeführt wurde. git rebase spielt die Commits eines Branchs auf einem anderen Commit erneut ab, wodurch neue Commit-Objekte und eine lineare Historie entstehen; die ursprünglichen Commits werden aufgegeben.

Warum es wichtig ist

Lineare Historie ist leichter zu lesen und zu bisektieren; Merge-Historie ist ehrlich über parallele Arbeit. Die Wahl ist bei gemeinsam genutzten Branches am wichtigsten: Pro Git formuliert die Regel unmissverständlich – Commits, die ausserhalb des eigenen Repositorys existieren und auf denen andere möglicherweise bereits aufgebaut haben, nicht rebasen, weil deren Historie dann von der eigenen abweicht.

So wird es angewendet

• Den eigenen, noch nicht veröffentlichten Topic-Branch vor dem Eröffnen eines Reviews auf den aktuellen Integrations-Branch rebasen, damit der Diff gegen frischen Code steht.
• Über das Review-Werkzeug in den Integrations-Branch mergen (oder Squash-mergen); den vom Team gewählten Stil konsistent beibehalten.
• Für die lokale Integration git pull --rebase verwenden, um störende Commits wie "merge branch main into main" zu vermeiden.
• Nach einem Rebase nur den eigenen Branch force-pushen, und --force-with-lease bevorzugen, damit nicht der Push einer anderen Person überschrieben wird.

Stolpersteine

Das Rebasen eines Branchs, den eine Kollegin oder ein Kollege ausgecheckt hat, erzeugt für diese Person doppelte Commits und Konflikte. Die Konfliktlösung während eines langen Rebase muss pro Commit wiederholt werden; vorheriges Squashen verringert das. Das Umschreiben der Historie zerstört Signaturen auf den umgeschriebenen Commits.