· 1 Min. Lesezeit
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.
Kurzer Nachtrag zum Experiment mit zwei Projektordnern (Folge 006).
Das Video zu dieser Folge
Dieses Video ist mit Zugangscode geschützt. Nach der Freischaltung bleibst du in diesem Browser angemeldet (localStorage), bis der Zugang abläuft oder du ihn zurücksetzt.
Du hast noch keinen ZugangsCode? Dann melde dich bei mir!
CONTACT_EMAIL).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 im Repo Tab „Commits“ (Commit-Verlauf) (oder Startseite des Repos mit Commit-Liste) siehst du die Einzelteile weiter, oft ein langer Stapel.
Merge (dein Freund fürs Team)
main: A --- B ------- M
\ /
feature: C - D - EM 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.