Git on kenji.blog

【Git-Befehle】Der Unterschied zwischen rebase und merge und deren richtige Anwendung in der Praxis

Sun, 13 Sep 2026 09:00:00 +0900

1. Einführung: Warum „merge oder rebase“ ein ewiges Thema ist

Git ist ein unverzichtbares Versionskontrollsystem in der modernen Softwareentwicklung. Wenn mehrere Entwickler gleichzeitig die Codebasis ändern, spielt das leistungsstarke Branching-Modell von Git seine Stärken aus. In der Teamentwicklung ist die Diskussion darüber, ob man merge oder rebase verwenden sollte, jedoch eines der Themen, das Entwickler vom Anfänger bis zum Experten immer wieder beschäftigt.

In diesem Artikel werden wir die Unterschiede im Mechanismus von git merge und git rebase tiefgehend untersuchen, indem wir die interne Struktur von Git, wie den DAG (gerichteter azyklischer Graph) und die mathematischen Eigenschaften von Commit-Hashes, entschlüsseln. Darüber hinaus werden wir anhand von konkreten Workflows ausführlich erklären, wie man diese beiden in der Praxis richtig einsetzt. Indem Sie nicht nur die Befehle kennenlernen, sondern auch verstehen, welche Berechnungen Git im Hintergrund durchführt, verlieren Sie die Angst vor Konflikten und können eine saubere, nachvollziehbare Historie aufbauen.

2. Interne Struktur von Git: Commit-Hashes und Objektmodell

Um zu verstehen, wie Git die Historie integriert, müssen wir zunächst wissen, wie Git Daten speichert. Git speichert nicht einfach nur die Unterschiede (Patches) von Dateiänderungen, sondern einen Schnappschuss (Snapshot) des gesamten Dateisystems zu einem bestimmten Zeitpunkt.

2.1 Kryptographische Eigenschaften von Commit-Hashes

Jeder Commit in Git wird durch eine 40-stellige Hexadezimalzahl, die mit der Hash-Funktion SHA-1 (Secure Hash Algorithm 1) basierend auf seinem Inhalt berechnet wird, eindeutig identifiziert. Ein Commit-Objekt besteht aus den folgenden Elementen:

Zeiger auf das Tree-Objekt: Ein Schnappschuss der Verzeichnisstruktur und der Dateien (Blobs) zu diesem Zeitpunkt.
Zeiger auf den Eltern-Commit: Die Hash-Werte eines oder mehrerer Eltern-Commits (der erste Commit hat keinen Elternteil, ein Merge-Commit hat zwei oder mehr).
Autor-Informationen (Author): Die Person, die den Code geschrieben hat, und das Datum.
Committer-Informationen (Committer): Die Person, die den Commit erstellt/angewendet hat, und das Datum.
Commit-Nachricht: Text, der die Absicht der Änderung erklärt.

Mathematisch ausgedrückt wird der Hash-Wert $H(C)$ für ein Commit-Objekt $C$ wie folgt definiert:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

Hierbei steht $\parallel$ für die Verkettung von Daten. Aufgrund der Eigenschaften der Hash-Funktion führt selbst die Änderung eines einzigen Zeichens in der Commit-Nachricht oder ein anderer Eltern-Commit zu einem völlig anderen Hash-Wert. Das bedeutet: Commits sind unveränderlich (immutable). Wenn später gesagt wird, dass rebase “die Historie umschreibt”, so bedeutet das in Wirklichkeit, dass “neue Commits erstellt werden, die einen ähnlichen Inhalt, aber unterschiedliche Hash-Werte haben”.

Die Größe des Hash-Raums beträgt $2^{160}$. Die Wahrscheinlichkeit $P$, dass eine Kollision auftritt (dass verschiedene Commits denselben Hash-Wert haben), kann mithilfe der Theorie des Geburtstagsparadoxons (Birthday Paradox) wie folgt angenähert werden (wobei $n$ die Anzahl der Commits ist):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

Diese Wahrscheinlichkeit ist extrem gering, und in der Praxis ist es nahezu unmöglich, dass Git-Commit-Hashes kollidieren.

3. Graphentheorie und DAG: Das mathematische Modell der Git-Historie

Die Commit-Historie von Git wird als „gerichteter azyklischer Graph“ (Directed Acyclic Graph, DAG) aus der Graphentheorie modelliert.

3.1 Was ist ein DAG (gerichteter azyklischer Graph)?

In einem Graphen $G = (V, E)$ ist $V$ die Menge der Commits (Knoten) und $E$ die Menge der gerichteten Kanten, die die Eltern-Kind-Beziehungen zwischen den Commits darstellen. In Git ist die Richtung der Kanten „vom Kind-Commit zum Eltern-Commit“ gerichtet, da neue Commits Zeiger auf vergangene Commits speichern.

graph BT
A["Commit A (Initial)"]
B["Commit B"]
C["Commit C (Main)"]
D["Commit D (Feature)"]
E["Commit E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

Das Hauptmerkmal eines DAG ist, dass „keine Zyklen (Schleifen) existieren“. Dadurch geraten Algorithmen, die die Commit-Historie zurückverfolgen, nie in eine Endlosschleife und erreichen sicher das Ende (den initialen Commit).

3.2 Topologische Sortierung und die Reihenfolge der Historie

Wenn Git die Historie mit Befehlen wie git log anzeigt, wird der DAG durch den Algorithmus der topologischen Sortierung (Topological Sort) als eindimensionale Liste geordnet. Für jede gerichtete Kante $u \to v$ im DAG ($u$ ist das Kind von $v$) wird die Liste so sortiert, dass $u$ vor $v$ steht.

4. Der Mechanismus und die Arten von git merge

Der grundlegendste Befehl zur Integration von Branch-Änderungen ist git merge. Je nach aktuellem Zustand wählt Git jedoch automatisch unterschiedliche Merge-Strategien aus.

4.1 Fast-Forward-Merge (–ff)

Wenn der Ziel-Branch (z. B. main) ein direkter Vorfahre des Quell-Branch (z. B. feature) ist, führt Git einen „Fast-Forward“-Merge (Vorspulen) aus. Dabei wird kein neuer Commit erstellt, sondern lediglich der Branch-Zeiger nach vorne verschoben.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

Ein Fast-Forward-Merge hält die Historie geradlinig, hat aber den Nachteil, dass der Kontext verloren geht, „welche Commit-Gruppe als eine einzige Feature-Entwicklung zusammengehörte“.

4.2 Non-Fast-Forward-Merge (–no-ff)

Wenn Sie explizit git merge --no-ff angeben, wird in jedem Fall ein neuer „Merge-Commit“ erstellt, selbst wenn ein Fast-Forward möglich wäre. Ein Merge-Commit ist ein spezieller Commit mit zwei Elternteilen.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Hauptarbeit 1"
merge feature type: NORMAL

Der Vorteil dieser Methode besteht darin, dass die Existenz und die Geschichte des Feature-Branches deutlich im DAG erhalten bleiben. Wenn ein Problem auftritt, kann durch Ausführen von git revert -m 1 <Hash des Merge-Commits> das gesamte Feature auf einmal sicher rückgängig gemacht (reverted) werden.

4.3 3-Way-Merge-Algorithmus (3-Wege-Merge)

Wenn der Ziel- und der Quell-Branch jeweils eigene Commits haben, führt Git einen 3-Way-Merge durch. Dabei durchsucht Git den DAG, um den „nächsten gemeinsamen Vorfahren“ (Lowest Common Ancestor, LCA) der beiden Branches zu finden.

Die zeitliche Komplexität $T_{\text{LCA}}$ des Algorithmus zum Finden des LCA ist linear in Bezug auf die Anzahl der Knoten $|V|$ und Kanten $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git vergleicht den „Zustand des LCA“, den „Zustand des aktuellen Branches“ und den „Zustand des anderen Branches“. Wenn die Änderungen nicht im Konflikt stehen, wird automatisch ein Merge-Commit generiert.

5. Der Mechanismus von git rebase und die Rekonstruktion der Historie

Während git merge die Historie „integriert“, wird sie bei git rebase „rekonstruiert“ (neu angesetzt).

5.1 Die Vorgänge hinter Rebase

Die internen Vorgänge beim Rebasen eines feature-Branches auf den main-Branch (git rebase main) sind wie folgt:

Finde den gemeinsamen Vorfahren (LCA) des feature-Branches und des main-Branches.
Speichere die Diffs (Änderungen) der Commits vom LCA bis zur Spitze des feature-Branches in einem temporären Bereich.
Verschiebe den Zeiger des feature-Branches auf die Spitze des main-Branches.
Wende die gespeicherten Diffs der Reihe nach auf die neue Basis (die Spitze von main) an (Cherry-Pick) und generiere so neue Commits.

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C (Main)"]
B --> D["Commit D (Altes Feature)"]
D -.-> E["Commit D' (Neues Feature)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

Hierbei ist wichtig, dass der durch den Rebase erstellte Commit $D'$ einen anderen Eltern-Commit als der ursprüngliche Commit $D$ hat und somit einen völlig anderen Hash-Wert besitzt (siehe Definition der Hash-Funktion $H(C)$ weiter oben).

5.2 Interaktives Rebase (Interactive Rebase)

Mit git rebase -i (oder --interactive) können Sie die Commit-Historie ganz nach Ihren Wünschen bearbeiten. Dies ist das mächtigste Werkzeug, um die lokale Historie zu bereinigen.

pick: Den Commit so übernehmen, wie er ist.
reword: Nur die Commit-Nachricht bearbeiten.
edit: Den Vorgang pausieren, um den Inhalt des Commits zu bearbeiten.
squash: Diesen Commit mit dem vorherigen Commit verschmelzen und auch die Nachrichten kombinieren.
fixup: Wie squash, jedoch wird die Nachricht dieses Commits verworfen.
drop: Den Commit vollständig löschen.

Aus mathematischer Sicht ergeben sich bei $N$ Commits in einem Branch folgende Variationen (Permutationen) $P$ an möglichen linearen Historien, die durch Ändern der Reihenfolge beim Rebase generiert werden können:

$$ P = N! $$

Git gibt Entwicklern $N!$ Möglichkeiten und erlaubt es so, die Historie in einem logischen und aufgeräumten Zustand zu halten.

6. Die Goldene Regel des Rebasens (The Golden Rule of Rebase)

rebase ist extrem mächtig, aber es gibt eine absolute Regel:

„Rebasen Sie niemals eine veröffentlichte, öffentliche Historie!“ (Never rebase public history)

6.1 Warum darf man eine öffentliche Historie nicht rebasen?

Git ist dezentralisiert. Die Commits, die Sie nach origin/main pushen, werden auch in die lokalen Repositories anderer Entwickler geklont (kopiert). Was passiert, wenn Sie einen bereits gepushten Commit rebasen, die Historie neu schreiben und diese mit git push --force erzwingen?

Der DAG in den lokalen Repositories der anderen Entwickler weicht grundlegend vom DAG auf dem Remote-Server ab. Wenn ein anderer Entwickler git pull ausführt, wird Git versuchen, Commits mit unterschiedlicher Historie gewaltsam zusammenzuführen. Dies führt zu massiven Konflikten und doppelten Commits (Commits mit gleichem Inhalt, aber unterschiedlichen Hashes), was das Repository in einen chaotischen Zustand versetzt.

Die eiserne Regel lautet: Führen Sie Rebase nur auf „lokalen Branches, die noch mit niemandem geteilt wurden“ aus.

7. Konfliktauflösung und git rebase –continue

Wenn mehrere Personen dieselbe Stelle in derselben Datei ändern, entsteht ein Konflikt (Conflict). Bei merge und rebase unterscheidet sich der Prozess der Konfliktauflösung.

7.1 Konfliktauflösung beim Merge

Bei git merge tritt die Konfliktauflösung nur einmal auf. Kurz bevor der endgültige Merge-Commit erstellt wird, werden alle Konflikte auf einmal behoben.

7.2 Konfliktauflösung beim Rebase

Aufgrund der Eigenschaft von git rebase, Commits nacheinander neu anzuwenden, besteht die Möglichkeit, dass bei jedem einzelnen Commit ein Konflikt auftritt.

Wenn während eines Rebase ein Konflikt auftritt, pausiert Git den Vorgang. Der Ablauf zur Lösung sieht wie folgt aus:

Öffnen Sie einen Editor oder eine IDE (wie VS Code) und beheben Sie die Konfliktmarkierungen (<<<<<<<, ====== und >>>>>>>) manuell.
Fügen Sie die bearbeitete Datei dem Index hinzu:
1

git add <bearbeitete Datei>
Setzen Sie den Rebase-Vorgang fort, ohne einen neuen Commit zu erstellen:
1

git rebase --continue

Wenn Sie den Rebase komplett abbrechen und in den ursprünglichen Zustand zurückkehren möchten, führen Sie folgenden Befehl aus:

1

git rebase --abort

(Wenn keine Konfliktauflösung erforderlich ist und Sie den gesamten Commit überspringen möchten, verwenden Sie git rebase --skip.)

8. Der richtige Einsatz in der Praxis (Workflow-Praxis)

Wie sollten Sie nun in der tatsächlichen Entwicklungsumgebung zwischen merge und rebase wählen? Hier stellen wir den standardmäßigsten und sichersten Ansatz vor.

8.1 [Szenario 1] Bereinigung der lokalen Arbeitshistorie (Verwendung von Rebase)

Angenommen, Sie haben während der Entwicklung in einem Feature-Branch viele kleine Commits angesammelt (z. B. “Tippfehler behoben”, “Temporär gespeichert” usw.). Bevor Sie einen Pull Request (PR) erstellen, nutzen Sie interaktives Rebase, um diese zu sinnvollen Einheiten zusammenzufassen.

1
2
3


# Ausführen, während Sie sich im feature-Branch befinden
git rebase -i HEAD~5
# (Ein Editor öffnet sich; nutzen Sie squash oder fixup, um die Historie zu bereinigen)

Dadurch können Sie eine saubere Commit-Historie erstellen, bei der die Absichten für den Reviewer leichter nachvollziehbar sind.

8.2 [Szenario 2] Aktualisierung auf den neuesten main-Branch (Verwendung von Rebase)

Wenn die Entwicklung länger dauert und fortlaufend Änderungen anderer Personen in den main-Branch gemergt werden, wird Ihr eigener feature-Branch veraltet sein. In diesem Fall aktualisieren Sie Ihren feature-Branch, indem Sie ihn auf den neuesten Stand von main rebasen.

1
2
3
4
5


# Die neuesten Informationen von main abrufen
git fetch origin

# Den feature-Branch auf den neuesten main-Branch aufsetzen
git rebase origin/main

Dadurch bleibt die Historie linear, und Sie können Konflikte bei späteren Merges vermeiden. Außerdem wird verhindert, dass überflüssige Merge-Commits (“Merge branch ‘main’ into feature”) erstellt werden.

8.3 [Szenario 3] Integration abgeschlossener Features (Verwendung von Merge)

Wenn die Entwicklung im feature-Branch abgeschlossen ist, kommt die Phase der Integration in den main-Branch. Hier verwenden Sie git merge --no-ff (das entspricht der Auswahl von “Create a merge commit” bei einem Pull Request auf GitHub).

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: Implementierung der Benutzer-Login-Funktion"
git push origin main

Dadurch bleibt im DAG des main-Branches ein Knotenpunkt in der Historie (Merge-Commit) erhalten, der besagt: „Hier wurde ein Feature gemergt“. Wenn Sie später die Historie betrachten, können Sie den Code pro Feature-Einheit viel leichter nachvollziehen.

9. Fazit (Zusammenfassung)

Bei der Arbeit mit Git haben extreme Ansätze wie „Alles mit Merge erledigen“ oder „Alles mit Rebase linear halten“ jeweils ihre Vor- und Nachteile.

Die Best Practice in der Praxis ist ein hybrider Ansatz: „Nutzen Sie rebase, um die private lokale Historie schön aufzuräumen, und verwenden Sie merge –no-ff für die öffentliche Integrationshistorie, um den Kontext zu erhalten.“

Lokal (persönlicher Arbeitsbereich): Verwenden Sie rebase, um unnötige Commits zu eliminieren, der neuesten Mainline zu folgen und eine lineare Historie beizubehalten.
Global (geteilter Arbeitsbereich): Verwenden Sie merge --no-ff, um die Existenz des Feature-Branches als Merge-Commit im DAG aufzuzeichnen und so Reverts und Tracking zu erleichtern.

Durch das Verständnis des mathematischen und architektonischen Hintergrunds, wie der Struktur des DAGs und der Funktionsweise von Hash-Funktionen, werden Git-Befehle von purem Auswendiglernen zum „Entwurf einer Historie mit Absicht“ erhoben. Beachten Sie die Goldene Regel des Rebasens, wählen Sie je nach Situation den optimalen Befehl und bauen Sie eine saubere Commit-Historie auf, die für das gesamte Team leicht lesbar und wartbar ist.

Häufige Fehler von Git-Anfängern und eine Sammlung von Lösungsbefehlen (Konfliktlösung etc.)

Sat, 12 Sep 2026 17:00:00 +0900

Häufige Fehler von Git-Anfängern und eine Sammlung von Lösungsbefehlen (Konfliktlösung etc.)

1. Einführung: Warum machen wir Fehler in Git?

In der Softwareentwicklung ist Git so unverzichtbar geworden wie Luft oder Wasser. Für viele Anfänger (und manchmal sogar für erfahrene Entwickler) kann sich Git jedoch wie eine „furchteinflößende, magische Blackbox“ anfühlen. Commits verschwinden, eine große Menge an Änderungen wird versehentlich in den falschen Branch gepusht, oder bisher unbekannte Fehlermeldungen bei Konflikten überschwemmen den Bildschirm… Wenn man in solche „Git-Fallen“ tappt, kommt der Arbeitsfortschritt oft komplett zum Erliegen, und im schlimmsten Fall fürchtet man, den Quellcode zu zerstören.

Warum ist Git so schwierig und fehleranfällig? Der Hauptgrund dafür ist: „Man lernt nur oberflächliche Befehle auswendig und wendet sie an, ohne zu verstehen, was im Inneren von Git passiert.“ Git basiert auf einer robusten Designphilosophie als verteiltes Versionskontrollsystem (DVCS), aber seine Benutzeroberfläche (CLI) ist nicht immer intuitiv.

Dieser Artikel kategorisiert zahlreiche „Missgeschicke (häufige Fehler)“, auf die Git-Anfänger in der Praxis häufig stoßen, und präsentiert konkrete Lösungsbefehle für jeden Fall. Es wird jedoch nicht nur eine einfache Liste von Befehlen (Cheat Sheet). Wir werden tiefgründig erklären, „warum der Fehler auftritt“ und „wie sich die Daten innerhalb von Git bewegen, wenn man diesen Befehl ausführt“, einschließlich der internen Struktur des .git-Verzeichnisses, des mathematischen Hintergrunds des dahinter arbeitenden Diff-Algorithmus sowie Mermaid-Diagrammen, auf mehr als 10.000 Zeichen.

Wenn Sie diesen Artikel bis zum Ende gelesen haben, sollten Sie von der Angst vor Git befreit sein und stattdessen davon überzeugt sein, dass „es keinen zuverlässigeren Partner als Git gibt“. Lassen Sie uns also in die tiefe Welt von Git eintauchen.

2. Der Abgrund von Git: Die interne Struktur des `.git`-Verzeichnisses verstehen

Der erste Schritt zur Erleichterung vieler Fehlerbehebungen besteht darin, zu verstehen, wie Git Daten speichert. Der versteckte Ordner .git im Stammverzeichnis Ihres Projekts ist das Herzstück von Git. Git ist kein System, das einfach Dateidifferenzen (Patches) der Reihe nach aufzeichnet, sondern verwaltet die Daten als einen Stream von Snapshots.

2.1 Das Objektmodell: Blob, Tree, Commit

Git verwendet hauptsächlich drei Objekte, um den Status des Repositorys darzustellen. Diese Objekte werden in .git/objects gespeichert.

Blob (Binary Large Object) Dieses Objekt speichert den eigentlichen Inhalt der Datei. Informationen wie Dateinamen oder Berechtigungen sind hier nicht enthalten. Reine Bytefolgen werden mit zlib komprimiert und durch einen SHA-1-Hashwert (40-stellige hexadezimale Zahl) identifiziert.
Tree Dieses Objekt stellt die Verzeichnisstruktur dar. Ein Tree-Objekt enthält Zeiger (SHA-1-Hashwerte) auf andere Tree-Objekte (Unterverzeichnisse) oder Blob-Objekte (Dateien) sowie deren Dateinamen und Zugriffsrechte. Es fungiert ähnlich wie ein UNIX-Verzeichnis.
Commit Dies enthält einen Zeiger auf das oberste Tree-Objekt des gesamten Repositorys zu einem bestimmten Zeitpunkt, zusammen mit Metadaten (Autor, Commit-Datum, Commit-Nachricht) sowie einem Zeiger auf den vorherigen Commit (Eltern-Commit).

graph TD
Commit1["Commit (Hash: 9f8a)"] --> Tree1["Tree (Hash: 4b82)"]
Tree1 --> Blob1["Blob (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["Tree (Hash: 3a2c) : src/"]
Tree2 --> Blob2["Blob (Hash: 5f1b) : app.js"]

2.2 Die wahre Identität von HEAD und Referenzen (Refs)

Das Wort HEAD, das man bei der Arbeit mit Git häufig sieht, ist eine symbolische Referenz (Symbolic Reference), die auf den aktuell ausgecheckten Branch (oder Commit) zeigt. Wenn Sie die Datei .git/HEAD in einem Texteditor öffnen, sehen Sie eine Zeichenfolge wie diese:

1

ref: refs/heads/main

Dies bedeutet: „Der aktuelle Status befindet sich an der Spitze des main-Branches.“ Wenn Sie dann .git/refs/heads/main öffnen, finden Sie dort einen 40-stelligen SHA-1-Hash, der auf das neueste Commit-Objekt zeigt. Ein Git-Branch ist lediglich ein leichtgewichtiger Zeiger (eine Datei), der auf einen bestimmten Commit zeigt. Wenn man diese Tatsache kennt, verschwindet die Angst, dass „alle Dateien gelöscht werden, wenn ich den Branch lösche“.

3. Git durch Mathematik entschlüsseln: Diff-Algorithmen und Hash-Funktionen

Wenn Git Konflikte erkennt oder Dateiunterschiede anzeigt, laufen im Hintergrund fortschrittliche Algorithmen ab.

3.1 Myers Diff-Algorithmus

Der standardmäßige Diff-Algorithmus in Git wurde von Eugene W. Myers entwickelt. Wenn wir zwei Textdateien $A$ und $B$ haben, kann das Problem, die „minimale Folge von Bearbeitungsschritten (Einfügungen und Löschungen)“ zu finden, um $A$ in $B$ umzuwandeln, als Problem des kürzesten Pfades in der Graphentheorie modelliert werden.

Seien die Längen der Zeichenfolgen $N$ bzw. $M$, und die Summe $V = N + M$. Der Myers-Algorithmus sucht nach der Bearbeitungsdistanz (Edit Distance) $D$. Die Zeitkomplexität dieses Algorithmus wird durch folgende Formel ausgedrückt:

$$ \mathcal{O}(V \cdot D) $$

Wenn die Differenz zwischen den Dateien klein ist (d. h. $D$ klein ist), arbeitet der Algorithmus sehr schnell mit $\mathcal{O}(V)$. Wenn die Dateien jedoch völlig unterschiedlich sind, gilt $D \approx V$, und die Worst-Case-Zeitkomplexität beträgt $\mathcal{O}(V^2)$.

3.2 Patience Diff und Histogram Diff

Obwohl der Myers-Algorithmus hervorragend ist, kann er Unterschiede generieren, die für Menschen nicht intuitiv (sinnlos) sind, z. B. wenn die Reihenfolge von Funktionen oder Klassen stark geändert wird. Um dieses Problem zu lösen, implementiert Git Patience Diff und Histogram Diff.

Patience Diff konzentriert sich auf „eindeutige Zeilen, die in beiden Dateien genau einmal vorkommen“ und findet deren längste gemeinsame Teilsequenz (Longest Common Subsequence: LCS). Wenn die Anzahl der eindeutigen Elemente $U$ ist, kann die Berechnung der LCS mit folgender Zeitkomplexität gelöst werden:

$$ \mathcal{O}(U \log U) $$

Wenn Sie das Gefühl haben, dass die Konfliktlösung schwierig ist, ist es eine Option, git diff --histogram zu verwenden oder diesen Algorithmus für die Merge-Strategie anzugeben (git merge -s recursive -X histogram).

3.3 SHA-1 und Kollisionswahrscheinlichkeit

Git verwaltet alle Objekte mit SHA-1-Hashwerten. Die Größe des Hashraums beträgt $2^{160}$. Bei einer Annäherung an die Wahrscheinlichkeit von Hash-Kollisionen (wenn unterschiedliche Inhalte denselben Hashwert haben) unter Verwendung des Geburtstagsparadoxons (Birthday Paradox) ist die Anzahl der Objekte $k$, die erforderlich ist, damit die Kollisionswahrscheinlichkeit $p$ 50% erreicht, wie folgt:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

Dies ist eine astronomische Zahl, und die Wahrscheinlichkeit, dass bei normaler Softwareentwicklung unbeabsichtigt eine Kollision auftritt, ist praktisch null. Daher arbeitet Git mit der Zuversicht, dass Hashwerte „absolute und eindeutige IDs“ sind.

4. Fallstudie 1: Auf den falschen Branch committet!

[Situation] Sie haben nicht bemerkt, dass Sie im main-Branch arbeiten, haben zügig Code für eine neue Funktion geschrieben und, man glaubt es kaum, sogar git commit ausgeführt. Dabei sollten Sie eigentlich einen Branch namens feature/login erstellen und dort arbeiten!

Lösung: `git reset` und Branch-Erstellung

In Git sind Commits unabhängige Objekte, und Branches sind nur Zeiger. Daher kann dieses Problem sofort mit der Operation „Einen neuen Branch erstellen und dann den Zeiger des aktuellen Branches zurückdrehen“ gelöst werden.

1
2
3
4
5
6
7
8
9


# 1. Einen neuen Branch erstellen, der auf den aktuellen Commit (den versehentlich erstellten) zeigt
$ git branch feature/login

# 2. Den Zeiger des main-Branches auf den vorherigen Commit (HEAD~1) zurücksetzen
# Die Verwendung von --keep ermöglicht ein sicheres Zurücksetzen, während die nicht committeten Änderungen im Arbeitsverzeichnis beibehalten werden.
$ git reset --keep HEAD~1

# 3. Zum richtigen Branch wechseln
$ git checkout feature/login

Illustration: Was ist intern passiert?

Lassen Sie uns die Verschiebung der Branch-Zeiger in diesem Moment mit gitGraph von Mermaid visualisieren.

gitGraph
commit id: "Initialer Commit"
commit id: "Bugfix"
commit id: "Falscher Commit" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

Zunächst zeigten main und HEAD auf den “Falscher Commit”, aber mit git branch feature/login wurde dort ein neuer Zeiger erstellt. Danach springt durch git reset nur der main-Zeiger zurück auf die Position “Bugfix”. Die Objekte selbst werden überhaupt nicht gelöscht.

5. Fallstudie 2: Ich möchte einen bereits gepushten Commit rückgängig machen!

[Situation] In der späten Nacht haben Sie verbuggten Code committet und diesen zudem mit git push origin main im Remote-Repository veröffentlicht. Sie bemerken den schwerwiegenden Bug und erblassen.

Lösung 1: Die Historie negieren mit `git revert` (Empfohlen/Sicher)

Bei der Teamentwicklung ist es strengstens verboten, die Historie von Commits, die bereits gepusht wurden, mit Befehlen wie git reset zu verändern. Dies führt zu Inkonsistenzen mit den lokalen Repositories anderer Entwickler. Der richtige Ansatz ist, „einen neuen Commit zu erstellen, der die Änderungen des fehlerhaften Commits vollständig umkehrt“. Das macht git revert.

1
2
3
4
5
6
7


# Einen Commit erstellen, der den neuesten Commit rückgängig macht
$ git revert HEAD
[main 7f3a8b2] Revert "Falsche Commit-Nachricht"
 1 file changed, 1 insertion(+), 10 deletions(-)

# Ins Remote-Repository pushen
$ git push origin main

gitGraph
commit id: "Commit A"
commit id: "Commit B (Fehler)"
commit id: "Commit B rückgängig machen" type: REVERSE

Die Historie geht weiter, und nur der Zustand des Codes wird zurückgesetzt.

Lösung 2: Die Historie verändern mit `git push --force-with-lease`

Wenn Sie gerade erst auf einen Branch gepusht haben, den nur Sie allein nutzen, ist es tolerierbar, die Historie umzuschreiben.

1
2
3
4
5
6
7


# Commit lokal zurücksetzen und korrigieren
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Korrekte Implementierung"

# Die Remote-Historie erzwungen überschreiben
$ git push origin feature/login --force-with-lease

--force-with-lease ist ein sicherer Force-Push, der Unfälle verhindert, bei denen die Arbeit anderer versehentlich überschrieben wird.

6. Fallstudie 3: Während der Arbeit zu einem anderen Branch wechseln (Die Magie von Stash)

[Situation] Sie sind gerade dabei, eine neue Funktion im Branch feature/A zu implementieren, und der Quellcode befindet sich in einem unvollständigen Zustand, der nicht einmal kompiliert. Plötzlich kommt vom Chef die Anweisung: „Es gibt einen kritischen Bug in der Produktionsumgebung des main-Branches, bitte beheben Sie ihn sofort!“

Lösung: Ausweichen mit `git stash`

git stash ist ein Befehl, mit dem nicht committete Änderungen vorübergehend in einem temporären Bereich abgelegt werden können.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Die Änderungen in Arbeit speichern (ausweichen)
$ git stash push -m "WIP: Feature A teilweise implementiert"

# 2. Wechseln zum main-Branch wird möglich
$ git checkout main
# ... (Notfall-Bugfix durchführen, committen, pushen) ...

# 3. Wenn die Arbeit beendet ist, zum ursprünglichen Branch zurückkehren
$ git checkout feature/A

# 4. Die zurückgestellten Änderungen wiederherstellen
$ git stash pop

Wenn Sie git stash ausführen, generiert Git intern zwei spezielle Commit-Objekte und speichert sie in der Referenz namens refs/stash. Letztlich ist ein Stash also auch nur ein „temporärer Commit ohne Namen“.

7. Fallstudie 4: Der furchteinflößende Zustand des “Detached HEAD”

[Situation] Sie wollten den Code zu einem bestimmten vergangenen Zeitpunkt überprüfen und haben git checkout 9f8a7b6 ausgeführt. Daraufhin wurde You are in 'detached HEAD' state. angezeigt. Sie haben wie gewohnt weiter committet, aber als Sie den Branch wechselten, waren die Commits plötzlich weg!

Der Mechanismus von Detached HEAD

Normalerweise zeigt HEAD auf einen Branch wie refs/heads/main. Wenn Sie jedoch einen bestimmten Commit direkt auschecken, zeigt HEAD direkt auf das Commit-Objekt. Dies nennt man einen Detached HEAD (abgetrennter HEAD).

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C"]
C --> D["Commit D"]
BranchMain["Branch: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

Selbst wenn Sie in diesem Zustand Commits stapeln, wird kein Branch diese neuen Commits verfolgen. In dem Moment, in dem Sie zu einem anderen Branch wechseln, gehen die neuen Commits verloren.

Lösung: Als neuen Branch speichern

Die Lösung besteht darin, an Ihrem aktuellen Standort einen neuen Branch zu erstellen.

1
2


# Einen neuen Branch an der aktuellen HEAD-Position erstellen und dorthin wechseln
$ git checkout -b feature/recovered-work

8. Fallstudie 5: Konfliktlösung beim Merge und Rebase

[Situation] Als Sie git merge oder git rebase ausgeführt haben, wurde CONFLICT (content) angezeigt, und der Prozess wurde abgebrochen.

Der Unterschied zwischen Merge und Rebase

Merge Führt einen 3-Wege-Merge (3-way merge) mit den neuesten Commits zweier Branches und ihrem gemeinsamen Vorfahren durch und erstellt einen Merge-Commit.
Rebase Speichert die Commits des aktuellen Branches vorübergehend und wendet sie auf die Spitze des Ziel-Branches neu an. Die Historie wird linear.

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

Methode zur Konfliktlösung

In der Datei, in der der Konflikt aufgetreten ist, sind Marker wie diese eingefügt:

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

Der Lösungsweg ist extrem simpel.

Entfernen Sie die Marker und korrigieren Sie den Code auf die richtige Version.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

Fügen Sie die aufgelöste Datei dem Staging-Bereich hinzu. git add hat die Rolle, „Git mitzuteilen, dass der Konflikt gelöst wurde“.
1

$ git add index.js

Schließen Sie den Prozess ab.

1
2
3
4
5


# Im Falle eines Merges
$ git commit -m "Merge-Konflikt in index.js gelöst"

# Im Falle eines Rebases
$ git rebase --continue

Wenn Sie in Panik geraten, können Sie mit $ git merge --abort oder $ git rebase --abort jederzeit abbrechen.

9. Fallstudie 6: Eine chaotische Commit-Historie! `git rebase -i`

[Situation] Es haben sich viele kleine Commits angesammelt, wie „Tippfehler korrigiert“, „doch noch geändert“, „Test hinzugefügt“. Wenn ich das so in main merge, wird die Historie unsauber.

Lösung: Interaktives Rebase

Mit git rebase -i (interactive) können Sie die Reihenfolge vergangener Commits ändern, mehrere Commits zu einem zusammenfassen (squash) oder die Commit-Nachrichten bearbeiten.

1
2


# Die letzten 3 Commits aufräumen
$ git rebase -i HEAD~3

Der Editor öffnet sich und es wird Folgendes angezeigt:

1
2
3


pick 1a2b3c4 Tippfehler korrigiert
pick 2b3c4d5 doch noch geändert
pick 3c4d5e6 Test hinzugefügt

Sie können dies wie folgt umschreiben:

1
2
3


pick 1a2b3c4 Implementierung von Funktion X
squash 2b3c4d5 doch noch geändert
squash 3c4d5e6 Test hinzugefügt

Wenn Sie dies speichern und schließen, werden diese 3 Commits wunderbar zu einem einzigen vereint.

10. Fallstudie 7: Ich weiß nicht, wann der Bug eingeführt wurde! `git bisect`

[Situation] Der aktuelle main-Branch hat einen Bug, aber beim Release vor einem Monat funktionierte noch alles normal. Sie möchten herausfinden, mit welchem Commit der Bug eingeführt wurde, aber bei mehr als 100 Commits ist das manuell unmöglich!

Lösung: Bug-Suche durch binäre Suche (Bisektion)

Git verfügt über ein integriertes Tool, das Fehler durch mathematische binäre Suche (Binary Search) findet. Da die Komplexität $\mathcal{O}(\log N)$ beträgt, können Sie den Fehler selbst bei 1000 Commits mit etwa 10 Tests identifizieren.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Die Suche starten
$ git bisect start

# Der aktuelle Commit hat den Bug (bad)
$ git bisect bad

# Vor einem Monat (z.B. Hash a1b2c3d) war alles normal (good)
$ git bisect good a1b2c3d

# Git checkt automatisch den mittleren Commit aus, führen Sie also den Test durch
# Wenn der Test erfolgreich ist:
$ git bisect good
# Wenn der Test fehlschlägt:
$ git bisect bad

Wenn Sie dies einfach wiederholen, wird Git Ihnen genau sagen: „Dieser Commit ist der erste fehlerhafte (bad) Commit“. Wenn Sie fertig sind, kehren Sie mit $ git bisect reset zum ursprünglichen Zustand zurück.

11. Das ultimative Sicherheitsnetz: `git reflog`

Die ultimative Technik gegen jegliche „Missgeschicke“ in Git ist git reflog. Git protokolliert den gesamten Verlauf lokaler Operationen (Bewegungen von HEAD) für einen bestimmten Zeitraum. Selbst wenn Sie versehentlich einen Branch löschen oder einen falschen Reset durchführen, können Sie den vergangenen Hashwert mit git reflog finden und durch ein einfaches git reset --hard dorthin wiederherstellen.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. Fazit

Wir haben ausführlich erläutert, welche Fehler Git-Anfänger häufig machen, welche Mechanismen in Git dahinterstecken und wie man sie behebt. Das Committen auf dem falschen Branch, das Rückgängigmachen gepushter Commits, die Verwendung von Stash, das Überleben bei einem Detached HEAD und das Lösen von Konflikten. Bei all diesen Dingen ist es wichtig, sich vorzustellen, „welche Objekte und Zeiger Git im Hintergrund manipuliert“.

Dateidifferenzen werden durch einen strengen Diff-Algorithmus berechnet, der als mathematische Formel ausgedrückt werden kann, und die Konsistenz der Historie wird durch kryptografische Hash-Funktionen gewährleistet. Wenn Sie diese schöne Designphilosophie verstehen, werden Sie erkennen, dass Git keineswegs eine „unheimliche Blackbox“ ist, sondern der stärkste Schild zum Schutz Ihres Quellcodes.

Wenn Sie das nächste Mal denken „Ich hab’s verbockt!“, schließen Sie nicht in Panik das Terminal, sondern atmen Sie tief durch und tippen Sie git status ein. Git wird Ihnen immer Hinweise zur Wiederherstellung geben.

Git on kenji.blog

【Git-Befehle】Der Unterschied zwischen rebase und merge und deren richtige Anwendung in der Praxis

1. Einführung: Warum „merge oder rebase“ ein ewiges Thema ist

2. Interne Struktur von Git: Commit-Hashes und Objektmodell

2.1 Kryptographische Eigenschaften von Commit-Hashes

3. Graphentheorie und DAG: Das mathematische Modell der Git-Historie

3.1 Was ist ein DAG (gerichteter azyklischer Graph)?

3.2 Topologische Sortierung und die Reihenfolge der Historie

4. Der Mechanismus und die Arten von git merge

4.1 Fast-Forward-Merge (–ff)

4.2 Non-Fast-Forward-Merge (–no-ff)

4.3 3-Way-Merge-Algorithmus (3-Wege-Merge)

5. Der Mechanismus von git rebase und die Rekonstruktion der Historie

5.1 Die Vorgänge hinter Rebase

5.2 Interaktives Rebase (Interactive Rebase)

6. Die Goldene Regel des Rebasens (The Golden Rule of Rebase)

6.1 Warum darf man eine öffentliche Historie nicht rebasen?

7. Konfliktauflösung und git rebase –continue

7.1 Konfliktauflösung beim Merge

7.2 Konfliktauflösung beim Rebase

8. Der richtige Einsatz in der Praxis (Workflow-Praxis)

8.1 [Szenario 1] Bereinigung der lokalen Arbeitshistorie (Verwendung von Rebase)

8.2 [Szenario 2] Aktualisierung auf den neuesten main-Branch (Verwendung von Rebase)

8.3 [Szenario 3] Integration abgeschlossener Features (Verwendung von Merge)

9. Fazit (Zusammenfassung)

Häufige Fehler von Git-Anfängern und eine Sammlung von Lösungsbefehlen (Konfliktlösung etc.)

Häufige Fehler von Git-Anfängern und eine Sammlung von Lösungsbefehlen (Konfliktlösung etc.)

1. Einführung: Warum machen wir Fehler in Git?

2. Der Abgrund von Git: Die interne Struktur des .git-Verzeichnisses verstehen

2.1 Das Objektmodell: Blob, Tree, Commit

2.2 Die wahre Identität von HEAD und Referenzen (Refs)

3. Git durch Mathematik entschlüsseln: Diff-Algorithmen und Hash-Funktionen

3.1 Myers Diff-Algorithmus

3.2 Patience Diff und Histogram Diff

3.3 SHA-1 und Kollisionswahrscheinlichkeit

4. Fallstudie 1: Auf den falschen Branch committet!

Lösung: git reset und Branch-Erstellung

Illustration: Was ist intern passiert?

5. Fallstudie 2: Ich möchte einen bereits gepushten Commit rückgängig machen!

Lösung 1: Die Historie negieren mit git revert (Empfohlen/Sicher)

Lösung 2: Die Historie verändern mit git push --force-with-lease

6. Fallstudie 3: Während der Arbeit zu einem anderen Branch wechseln (Die Magie von Stash)

Lösung: Ausweichen mit git stash

7. Fallstudie 4: Der furchteinflößende Zustand des “Detached HEAD”

Der Mechanismus von Detached HEAD

Lösung: Als neuen Branch speichern

8. Fallstudie 5: Konfliktlösung beim Merge und Rebase

Der Unterschied zwischen Merge und Rebase

Methode zur Konfliktlösung

9. Fallstudie 6: Eine chaotische Commit-Historie! git rebase -i

Lösung: Interaktives Rebase

10. Fallstudie 7: Ich weiß nicht, wann der Bug eingeführt wurde! git bisect

Lösung: Bug-Suche durch binäre Suche (Bisektion)

11. Das ultimative Sicherheitsnetz: git reflog

12. Fazit

2. Der Abgrund von Git: Die interne Struktur des `.git`-Verzeichnisses verstehen

Lösung: `git reset` und Branch-Erstellung

Lösung 1: Die Historie negieren mit `git revert` (Empfohlen/Sicher)

Lösung 2: Die Historie verändern mit `git push --force-with-lease`

Lösung: Ausweichen mit `git stash`

9. Fallstudie 6: Eine chaotische Commit-Historie! `git rebase -i`

10. Fallstudie 7: Ich weiß nicht, wann der Bug eingeführt wurde! `git bisect`

11. Das ultimative Sicherheitsnetz: `git reflog`