Artikel · 03.10.2026

Folge 007: Merge oder Rebase: Warum die Historie manchmal lügt

Nach dem Zusammenführen sieht’s im Tool oft leer aus. Auf GitHub steckt trotzdem alles drin. Kurz erklärt, ohne Git-Guru-Werbung.

#GitHub

Kurzer Nachtrag zum Experiment mit zwei Projektordnern (Folge 006).

Was dich im Tool verwirrt

Nach einem Merge kann der Graph so aussehen, als hättest du nur noch ein paar Commits. Die vielen Schritte davor stecken im Merge-Commit drin. Auf GitHub unter „Commits“ siehst du die Einzelteile weiter (im Video z. B. 21 Stück).

Merge (dein Freund fürs Team)

main:     A --- B ------- M
               \         /
feature:        C - D - E

M fasst zusammen. Nachvollziehbar, robust.

Rebase (die lineare Alternative)

Rebase: Commits C D E würden hinten an main hängen, als wäre alles nacheinander passiert. Hübsch, aber: nicht rebasen, was andere schon gezogen haben.

Was du wirklich brauchst

Stand ist gespeichert. Du kannst alte Dateiversionen ansehen („Copyright früher vs. jetzt“). Ob Merge oder Rebase. Geschmackssache. Mit KI-Agent reicht Merge + Pull vor Push. Branches und Preview vor dem Merge auf main: Folge 012.