Warum ich fast nie `git pull` benutze

Ich vermeide bewusst den einfachen Befehl git pull in meinem Alltag. Stattdessen nutze ich fast immer git pull --rebase.
Warum das Sinn macht, wird klar, wenn man versteht, was git pull eigentlich tut – und warum es die Commit-Historie oft unnötig verschmutzt.

Das Problem mit dem normalen git pull

Stell dir dieses typische Szenario vor:

• Du beginnst mit der Entwicklung eines neuen Features vom aktuellen Stand von main.
• Während du arbeitest, taucht ein kritischer Bug auf und ein Kollege soll ihn fixen.
• Er checkt denselben Commit aus, behebt den Bug, committed und pusht.
• Wenn du mit deinem Feature fertig bist und pushen willst, beschwert sich Git:
  ! [rejected] ... Updates were rejected because the remote contains work that you do not have locally.

Du musst jetzt den Bugfix pullen, bevor du pushen kannst. Ein normales git pull führt einen Merge durch – und erzeugt dabei einen zusätzlichen Merge-Commit (oft leer oder bedeutungslos, nur „Merge branch 'main' of origin/main“).

Im Laufe der Zeit, besonders in aktiven Teams, sieht die Historie dann so aus:

Das macht git log, git blame, Debugging mit bisect und Cherry-Picking deutlich schwerer – du musst dich durch lauter nutzlose Merge-Commits wühlen, um die eigentliche Arbeit zu finden.

Die saubere Lösung: git pull --rebase

Statt zu mergen, nutze einfach:

1git pull --rebase

Was passiert dabei (in einem Befehl):

1. Holt die neuesten Änderungen vom Remote.
2. Legt deine lokalen Commits vorübergehend zur Seite.
3. Wendet die Remote-Commits an.
4. Spielt deine lokalen Commits danach wieder oben drauf.

Ergebnis: eine lineare Historie – ohne zusätzliche Merge-Commits.

• Add new payment feature
• Improve checkout styling
• Fix critical bug in login < Remote-Commit
• Initial commit

Selbst wenn du oder dein Kollege mehrere Commits gemacht habt, funktioniert Rebase sauber mit der ganzen Kette.

Und was ist mit Merge-Konflikten?

Konflikte können natürlich trotzdem auftreten – Rebase verhindert sie nicht.

Wenn während git pull --rebase ein Konflikt entsteht:

• Git hält an und zeigt die betroffenen Dateien.
• Du löst sie wie gewohnt, dann:
  git add
git rebase --continue
• Oder wenn es zu kompliziert wird oder du abbrichst: git rebase --abort
  > Das macht alles rückgängig und stellt deinen Branch exakt so wieder her, wie er vor dem Pull war.

Danach kannst du bei Bedarf ein normales git pull (Merge) machen oder den Rebase nochmal versuchen.

Mach es zur Gewohnheit (sehr empfohlen)

Damit du nie wieder drüber nachdenken musst: git config --global pull.rebase true

Jetzt macht ein einfaches git pull automatisch --rebase.
(Falls du doch mal mergen willst, kannst du explizit git pull --no-rebase schreiben.)

Wichtiger Sicherheitshinweis:

Rebase schreibt Historie um – nie Commits rebasen, auf denen andere bereits aufbauen (öffentliche / geteilte Branches). Bei persönlichen Feature-Branches oder beim Tracking von main ist --rebase sicher und sorgt für eine schöne Historie.

Zusammenfassung – mein Workflow

• Immer zuerst `git pull --rebase` versuchen (oder einfach git pull mit globaler Einstellung).
• Lineare, saubere Historie -> viel leichteres Debuggen, Lesen von Logs, bisect.
• Konflikt? Während Rebase lösen oder mit git rebase --abort sicher abbrechen.
• Keine nutzlosen Merge-Commits mehr, die die Historie verschandeln.

Nutzt ihr --rebase standardmäßig, oder bevorzugt ihr Merge-Commits wegen besserer Nachverfolgbarkeit?
Schreibt gerne in die Kommentare – bin gespannt auf eure Erfahrungen!