← Alle Beiträge

Techniken, damit Rebasen weniger Kopfschmerzen macht

Auf dieser Seite

Ich sehe oft, dass Entwickler main in ihre Feature-Branches mergen und Pull Requests (PRs) öffnen, die Commits aus anderen Branches enthalten. Das führt zu „Git-Spaghetti“, und das hat mehrere Folgen:

  • Es verkompliziert die Commit-Historie
  • Es erhöht das Risiko von Konflikten, die für andere schwer zu lösen sind
  • Es kann Änderungen einschleppen, die noch nicht bereit für main sind
  • Es erschwert das Code Review, weil fremde Änderungen vom eigentlichen Zweck des PR ablenken

Soft Reset vor dem Rebase

Nutze git reset, um zu dem Punkt zurückzuspulen, an dem dein Branch vom Main-Branch abgezweigt ist. Deine Änderungen bleiben dabei im Arbeitsverzeichnis erhalten und lassen sich sauberer und ordentlicher committen.

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

Vorteile:

  • Behält deine Änderungen im Arbeitsverzeichnis
  • Vereinfacht den Rebase, weil weniger Commits zu verwalten sind
  • Ergibt eine sauberere, aussagekräftigere Commit-Historie
  • Weniger Druck, eine Commit-Nachricht zu finden, weil du sie einfach zu einem Commit zusammenquetschst

Fetch statt Pull

Führe git fetch aus, um dein Repository mit den neuesten Änderungen vom Remote zu aktualisieren, ohne diese automatisch in deinen lokalen Branch zu mergen. So kannst du die Änderungen prüfen, bevor du entscheidest, wie du sie integrierst.

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

Vorteile:

  • Du entscheidest, wann du neue Änderungen aus deinem Team übernimmst
  • Du verstehst neue Commits besser, bevor du mergst oder rebast
  • Hilft, eine lineare und saubere Commit-Historie zu behalten