Git Merge Konflikt lösen: Schritt für Schritt zur Lösung

Wie können Sie einen Git Merge Konflikt lösen?

Ein Git Merge Konflikt entsteht, wenn zwei Branches dieselben Zeilen unterschiedlich ändern und Git nicht entscheiden kann, welche Version gilt. Um ihn zu lösen, finden Sie die Dateien mit git status, behalten in jeder Datei den richtigen Inhalt, entfernen die Markierungen, führen git add aus und schließen den Merge ab. Abbrechen ist jederzeit möglich.

Keine Panik. Zunächst: Ein Konflikt bedeutet nicht, dass Git kaputt ist. Anders gesagt: Git sagt Ihnen damit, dass hier eine menschliche Entscheidung nötig ist. Ihre Arbeit ist in den meisten Fällen sicher, denn bis zum Commit können Sie noch zurück.

In diesem Beitrag folgen wir der Diagnosereihenfolge, die wir in der Praxis sehen. Zunächst geht es um den häufigsten Fall, danach um seltenere Fälle. Außerdem sind die Befehle kurz, und wir erklären bei jedem Schritt, warum er wichtig ist.

Was ist die Schnelllösung in 7 Schritten?

Zunächst brauchen Sie eine ruhige Reihenfolge. Die folgende Liste zeigt, wie Sie einen Git Merge Konflikt lösen, und sie gilt für Merge, Pull und Rebase gleichermaßen. Den kleinen Unterschied beim Rebase erklären wir weiter unten.

1. Führen Sie git status aus und notieren Sie die Dateien unter "Unmerged paths".
2. Öffnen Sie dann die erste Datei im Editor und suchen Sie die Konfliktmarkierungen.
3. Entscheiden Sie in jedem Konfliktblock, welcher Inhalt bleibt. Manchmal stimmt also eine Seite, manchmal braucht es eine Mischung aus beiden.
4. Löschen Sie die Markierungszeilen vollständig. In der Datei darf nur der endgültige Code stehen.
5. Speichern Sie die Datei und markieren Sie sie danach mit git add dateiname als erledigt.
6. Starten Sie anschließend Tests oder Build. Ein gelöster Konflikt ist nämlich noch kein funktionierender Code.
7. Beim Merge führen Sie git commit oder git merge --continue aus. Beim Rebase verwenden Sie git rebase --continue.

Wenn Sie nicht weiterkommen, rufen Sie dann einfach erneut git status auf. Daher nennt die Ausgabe meist den nächsten Schritt.

Warum entsteht ein Merge Konflikt in Git?

Ein Konflikt beginnt, wenn Git zwei Änderungen nicht automatisch zusammenführen kann. Denn Git arbeitet zeilenweise. Ändern zwei Personen verschiedene Dateien oder weit entfernte Stellen derselben Datei, gibt es kein Problem. Ändern beide jedoch dieselben Zeilen, weiß Git nicht, welche Fassung stimmt.

Die häufigsten Ursachen sind diese:

• Zwei Entwickler haben dieselbe Funktion oder Konfigurationszeile geändert.
• Ein langlebiger Branch hat sich weit vom Hauptzweig entfernt.
• Jemand hat eine Datei gelöscht oder umbenannt, während eine andere Person sie bearbeitet hat.
• Ein automatischer Formatierer hat die Einrückung der ganzen Datei geändert.
• Befehle wie git stash pop, git cherry-pick oder git revert haben alte Änderungen auf neuen Code angewendet.

Zum Beispiel können zwei Personen dieselbe Preiskonstante auf unterschiedliche Werte setzen. Git kann nicht beide behalten, denn es gibt eine Zeile und zwei Kandidaten. Deshalb hält es an und fragt Sie.

Wichtig ist: Ein Konflikt ist kein Fehler, sondern ein normaler Ablauf. Je größer das Team, desto öfter sehen Sie ihn. Das Ziel lautet also nicht null Konflikte. Das Ziel ist also, sie klein und einfach zu halten.

Was bedeuten die Konfliktmarkierungen?

Zunächst schreibt Git den Konfliktbereich direkt in die Datei. Drei Markierungszeilen zeigen Ihnen, was passiert ist. Der folgende Block ist ein Beispiel zum Verständnis:

<<<<<<< HEAD
preis = 100
=======
preis = 120
>>>>>>> feature-branch

So lesen Sie ihn:

• Alles zwischen der ersten Markierung und der Zeile ======= ist der Inhalt Ihres aktuellen Branches (HEAD).
• Alles zwischen ======= und der letzten Markierung ist der Inhalt des Branches, den Sie hereinholen.
• Die letzte Markierungszeile nennt den Branch oder Commit. Daher wissen Sie, woher der Inhalt kommt.

Diese drei Zeilen gehören nicht zu Ihrer Datei. Lassen Sie sie stehen, schlägt der Build fehl, weil die Syntax bricht. Schlimmer noch: Die Markierungen könnten in die Produktion gelangen. Entfernen Sie sie deshalb immer.

Möchten Sie mehr Kontext, setzen Sie git config merge.conflictStyle diff3. Dann sehen Sie zusätzlich den Inhalt des gemeinsamen Vorfahren. Somit lässt sich die Frage, was jede Seite geändert hat, leichter beantworten. Details finden Sie in der Git Dokumentation zu merge.

Wie sehen Sie, welche Dateien einen Konflikt haben?

Verschaffen Sie sich zunächst einen Überblick. Denn wer den Umfang kennt, bleibt ruhig. Die Ausgabe von git status zeigt zwei Gruppen: automatisch zusammengeführte Dateien und Dateien unter "Unmerged paths".

Nur die Namen der Konfliktdateien zeigt dieser Befehl:

git diff --name-only --diff-filter=U

Auch die Statusangaben sind wichtig:

• "both modified": Beide Seiten haben die Datei geändert. Das ist der häufigste Fall, daher prüfen Sie ihn zuerst.
• "deleted by us" oder "deleted by them": Eine Seite hat die Datei gelöscht, die andere sie bearbeitet.
• "both added": Beide Seiten haben eine unterschiedliche Datei mit demselben Namen hinzugefügt.

Bei einem Löschkonflikt sehen Sie dagegen keine Markierungszeilen. Die Entscheidung ist einfach, muss aber bewusst fallen: Datei behalten oder entfernen. Zum Behalten nutzen Sie git add, zum Entfernen git rm.

Notieren Sie außerdem andere offene Änderungen im Arbeitsverzeichnis. Außerdem hilft die Notiz Ihnen, falls Sie später abbrechen. Sonst verwechseln Sie nach dem Abbruch leicht, was Ihnen gehört.

Wie wählen Sie in der Datei den richtigen Inhalt?

Jeder Konfliktblock bietet drei Möglichkeiten: Ihre Seite behalten, die andere Seite behalten oder beide kombinieren. Die richtige Wahl erfordert, den Code zu lesen. Deshalb automatisieren Sie diesen Schritt nicht.

In der Praxis stellen wir diese Fragen der Reihe nach, denn die richtige Antwort steckt oft in der Absicht und nicht in der Syntax:

• Dienen beide Änderungen demselben Ziel, oder decken sie zwei verschiedene Bedürfnisse ab?
• Welche Seite beantwortet die neuere Anforderung?
• Falls beide nötig sind: Kollidieren Reihenfolge oder Benennung?
• Müssen Sie mit der Autorin oder dem Autor sprechen?

Allerdings überspringen die meisten die letzte Frage. Wenn Sie nicht wissen, warum die andere Seite die Zeile geändert hat, raten Sie also nicht. Lesen Sie stattdessen die Commit Nachricht. git log --merge -p dateiname zeigt die Commits, die zum Konflikt beitragen.

Beispielszenario: Eine Entwicklerin hat eine Funktion umbenannt, ein Kollege hat in derselben Funktion eine neue Bedingung ergänzt. Das richtige Ergebnis kombiniert beides, also bleiben neuer Name und neue Bedingung zusammen. Nur eine Seite zu wählen, würde dagegen still eine Funktion verlieren.

Wie schließen Sie die Lösung mit git add und Commit ab?

Danach müssen Sie Git mitteilen, dass die Datei fertig ist. Das erledigt git add. Konkret nimmt der Befehl die Datei in den Index auf und entfernt den Konfliktstatus.

Haben Sie das für alle Dateien getan, rufen Sie git status erneut auf. Sehen Sie eine Meldung wie "all conflicts fixed", sind Sie fast am Ziel. Danach folgt:

git add dateiname
git commit
# oder: git merge --continue

Die Commit Nachricht ist meist vorausgefüllt. Sie kann zum Beispiel die Konfliktdateien auflisten. Sie dürfen sie behalten oder einen Satz ergänzen, warum Sie so gelöst haben. Daher muss das Team später nicht fragen, warum eine Zeile so aussieht.

Es gibt allerdings eine Falle. git add . ist schnell getippt, nimmt aber auch eine Datei auf, in der noch Markierungen stehen. Führen Sie deshalb zuerst git diff --check aus. Der Befehl warnt nämlich vor übrig gebliebenen Markierungszeilen. So verhindern Sie einen fehlerhaften Commit.

Wie können Sie beim Rebase einen Git Merge Konflikt lösen?

Rebase wendet Ihre Commits einzeln auf eine neue Basis an, also tritt der Konflikt eventuell mehrmals auf. Deshalb kann ein Konflikt bei jedem Commit neu auftreten. Die Logik bleibt gleich: Datei lösen, dann git add. Der Unterschied ist, dass Sie am Ende keinen Commit schreiben.

Der richtige Befehl beim Rebase lautet:

git add dateiname
git rebase --continue

Damit geht es zum nächsten Commit. Dann wiederholen Sie den Vorgang, falls ein weiterer Konflikt auftritt. Ist der letzte Commit angewendet, endet der Rebase. Wird ein Commit komplett überflüssig, lässt git rebase --skip ihn aus. Nutzen Sie das trotzdem nur, wenn Sie sicher sind.

Außerdem tauschen "ours" und "theirs" beim Rebase ihre Bedeutung. Der Grund: Git legt Ihre eigenen Commits nacheinander auf einen anderen Branch. Konkret zeigt "ours" also auf den Basis Branch, "theirs" auf Ihre Commits, die gerade neu angewendet werden. Die Git Dokumentation zu rebase erklärt das genauer.

Erwarten Sie viele Konflikte, überrascht ein einzelner Merge Sie oft weniger als ein Rebase. Die Vergleichstabelle weiter unten fasst den Unterschied zusammen.

Wie brechen Sie Merge oder Rebase ab, wenn Sie aussteigen wollen?

Wird die Lösung unübersichtlich, können Sie also zurück. Vor dem Commit lässt sich der ganze Vorgang abbrechen. Der passende Befehl hängt davon ab, was Sie gestartet haben:

• Beim Merge nutzen Sie git merge --abort. Dann versucht Git, den Zustand vor dem Merge wiederherzustellen.
• Beim Rebase nutzen Sie git rebase --abort. Der Branch kehrt in den Zustand vor dem Rebase zurück.
• Beim Cherry Pick nutzen Sie git cherry-pick --abort.

Allerdings ist eine Warnung wichtig. Hatten Sie vor dem Merge nicht committete Änderungen, stellt der Abbruch diese nicht in jedem Fall wieder her. Die Git Dokumentation sagt das deutlich. Daher sollten Sie vor einem Merge das Arbeitsverzeichnis sauber halten oder zuerst committen oder stashen.

Nach dem Abbruch ist Ihr Branch zwar wieder wie vorher, der Konflikt selbst verschwindet aber nicht. Versuchen Sie denselben Merge erneut, sehen Sie dann denselben Konflikt. Stattdessen kann es helfen, zuerst den Hauptzweig in Ihren Branch zu holen und den Konflikt in kleineren Teilen zu lösen.

Wie hilft das Merge Werkzeug im Editor bei einem Konflikt?

Zum Glück müssen Sie die Markierungen nicht von Hand löschen. Die meisten modernen Editoren färben die Konfliktblöcke ein. Außerdem bieten sie klickbare Optionen an, um die aktuelle Änderung, die eingehende Änderung oder beide zu übernehmen.

Visual Studio Code ist ein Beispiel. Details stehen in der VS Code Dokumentation zur Quellcodeverwaltung. Für Erweiterungen und Einstellungen hilft unser Vergleich von VS Code und Visual Studio.

Git bringt auch ein eigenes Werkzeug mit: git mergetool. Es startet ein externes Merge Programm Ihrer Wahl. Ihr bevorzugtes Werkzeug legen Sie mit der Einstellung merge.tool fest. Zudem bleiben oft Sicherungsdateien mit der Endung .orig zurück. Committen Sie diese nicht.

Visuelle Werkzeuge haben allerdings ein Risiko. Ein Klick auf "diese Seite übernehmen" geht nämlich sehr schnell. Diese Bequemlichkeit kann also zur Nachlässigkeit werden. Lesen Sie deshalb vor jeder Übernahme beide Seiten. Vergessen Sie danach die Tests nicht.

Ist es sicher, mit --ours oder --theirs eine Seite komplett zu wählen?

Manchmal stimmt in einer Datei nur eine Seite. Ein Beispiel ist eine Build Ausgabe, die Sie ohnehin aus dem Quellcode neu erzeugen. Dann können Sie mit einem Befehl eine Seite wählen:

git checkout --ours -- dateiname
git checkout --theirs -- dateiname

Der erste Befehl holt die Version Ihres aktuellen Branches, der zweite die eingehende Version. Danach brauchen Sie git add. Beim Merge ist "ours" Ihr Branch. Beim Rebase ist es dagegen genau umgekehrt.

Das Risiko: Wählen Sie eine ganze Datei, verlieren Sie jede Änderung der anderen Seite in dieser Datei, auch die ohne Konflikt. Das heißt, ein Konflikt in einer Zeile kann Hunderte Zeilen Arbeit löschen. Gehen Sie deshalb bewusst vor, und zwar Datei für Datei.

Zwei ähnlich klingende Optionen werden oft verwechselt:

• git merge -X ours behält Ihre Seite nur in den Konfliktbereichen. Änderungen ohne Konflikt werden trotzdem übernommen.
• git merge -s ours ignoriert alle Änderungen des anderen Branches, vermerkt ihn aber in der Historie als zusammengeführt.

Die zweite Option ist sehr mächtig und meistens nicht gewollt. Sind Sie unsicher, verzichten Sie daher darauf.

Wie lösen Sie einen Konflikt in Lockfiles wie package lock?

Lockfiles wie package-lock.json oder yarn.lock erzeugen Werkzeuge. Zeilen von Hand zusammenzuführen ist deshalb fehleranfällig. Der Abhängigkeitsbaum hängt zusammen, daher zerstört eine falsche Zeile seine Konsistenz.

So gehen Sie in der Regel vor:

1. Lösen Sie zunächst den Konflikt in package.json mit eigenem Urteil. Entscheiden Sie dabei, welche Pakete beide Seiten brauchen.
2. Nehmen Sie für das Lockfile die Version einer Seite, zum Beispiel mit git checkout --theirs -- package-lock.json.
3. Führen Sie danach npm install aus. Dann bringt das Werkzeug das Lockfile mit der aktuellen package.json in Einklang.
4. Fügen Sie das neue Lockfile mit git add hinzu und starten Sie die Tests.

Die npm Dokumentation zu package lock ist eine gute Referenz. Stoßen Sie dabei auf einen Fehler im Abhängigkeitsbaum, hilft unser Beitrag zum npm ERESOLVE Fehler.

Eine wichtige Regel: Das Lockfile zu löschen und komplett neu zu erzeugen, ist der letzte Ausweg. Sonst können sich alle Versionen verschieben, auf die Ihr Team sich verlässt.

Wie können Sie bei Binärdateien einen Git Merge Konflikt lösen?

Binärdateien wie Bilder, PDFs, Designdateien oder komprimierte Pakete lassen sich nicht zeilenweise zusammenführen. Git schreibt deshalb keine Markierungen hinein. Es meldet nur, dass beide Seiten die Datei geändert haben, und wartet auf Ihre Wahl.

Die Lösung ist einfach, braucht aber Sorgfalt. Auch hier gilt: Sie wollen den Git Merge Konflikt lösen, ohne eine Version zu verlieren.

1. Entscheiden Sie, welche Version stimmt. Öffnen Sie bei Bedarf beide Versionen und vergleichen Sie sie dann manuell.
2. Holen Sie die richtige Seite mit git checkout --ours -- datei oder mit --theirs.
3. Zuletzt markieren Sie die Datei mit git add.

Haben beide Seiten unterschiedliche, nötige Änderungen gemacht, kann Git sie somit nicht kombinieren. Dann müssen Sie die Änderungen von Hand im passenden Programm zusammenführen, etwa in einem Designprogramm. Eine Regel zur Zuständigkeit hilft hier sehr: Es bearbeitet immer nur eine Person gleichzeitig.

Zudem verursacht es andere Probleme, große Binärdateien im Repository zu halten. Überlegen Sie, ob Sie dafür eine getrennte Ablage nutzen können.

Worin unterscheiden sich Konflikte bei Merge und Rebase?

Beide Verfahren erzeugen dieselben Markierungen, also lesen Sie sie gleich. Der Unterschied liegt darin, wann und wie oft der Konflikt auftritt. Die folgende Tabelle fasst ihn zusammen.

Kurz gesagt: Merge ist auf geteilten Branches berechenbarer. Auf Ihrem eigenen Branch hinterlässt Rebase dagegen eine sauberere Historie. Daher sollten die Regeln Ihres Teams entscheiden, was Sie nutzen.

Welche Ursache, welches Symptom und welche Lösung gehören zusammen?

Wer den Konflikttyp früh erkennt, spart Zeit. Die folgende Tabelle ordnet die häufigsten Situationen ihren Ursachen und Lösungen zu. Die Reihenfolge geht vom wahrscheinlichsten zum unwahrscheinlichsten Fall.

Diese Tabelle ist ein Ausgangspunkt. Natürlich bringt jedes Projekt eigene Details mit, denn Teams arbeiten verschieden. Trotzdem gilt die Reihenfolge: erst die Markierung lesen, dann den Typ bestimmen, zuletzt den Befehl wählen.

Wie prüfen Sie, ob Ihre Lösung korrekt ist?

Einen Konflikt zu lösen und ihn richtig zu lösen, sind zwei verschiedene Dinge. Selbst wenn Git die Datei als zusammengeführt ansieht, also zusammengeführt meldet, können Logikfehler bleiben. Bauen Sie deshalb vor dem Commit eine kurze Prüfroutine ein.

• Suchen Sie vergessene Markierungen mit git diff --check.
• Zweitens bauen oder starten Sie das Projekt. Ein Syntaxfehler kann den Konflikt überlebt haben.
• Führen Sie die vorhandenen Tests aus, vor allem jene, die die Konfliktdateien berühren.
• Schließlich prüfen Sie das Endergebnis mit git diff --staged.
• Bitten Sie wenn möglich die andere Autorin oder den anderen Autor um einen kurzen Blick.

Zudem hilft hier eine Debugging Gewohnheit. Geht etwas schief, arbeiten Sie sich mit den Methoden aus unserem Beitrag zu Debugging Techniken für Entwickler in kleinen Schritten voran.

Einen fertigen Merge können Sie auch nach dem Commit rückgängig machen. Sagen Sie Ihrem Team aber vorher Bescheid, wenn die Historie geteilt ist.

Wie verringern Sie von Anfang an die Zahl der Konflikte?

Null Konflikte erreichen Sie allerdings nicht. Häufigkeit und Größe können Sie aber senken. Diese Gewohnheiten bewähren sich in der Praxis, wenn Sie künftig weniger Konflikte lösen möchten:

• Führen Sie klein und oft zusammen. Ein Branch, der Wochen lebt, ist ein Berg aus Konflikten.
• Aktualisieren Sie Ihren Branch regelmäßig vom Hauptzweig. So lösen Sie Konflikte, solange sie klein sind.
• Machen Sie kleine Commits. Ein Commit sollte also einem Zweck dienen.
• Legen Sie Formatierungsänderungen in einen eigenen Commit. Dann vermischen sich inhaltliche Änderungen nicht mit Einrückungsrauschen.
• Legen Sie Code Zuständigkeiten fest. Dann ist klar, wem welches Modul gehört.
• Sprechen Sie sich ab, wenn mehrere Personen gleichzeitig in derselben Datei arbeiten.

Denken Sie außerdem an git rerere. Lösen Sie denselben Konflikt immer wieder, was bei langlebigen Branches oft vorkommt, kann Git Ihre frühere Lösung merken und anwenden. Sie schalten das dann mit der Einstellung rerere.enabled ein.

Sind Git Befehle neu für Sie, ist unsere Anleitung zu den wichtigsten Git Befehlen ein guter Start. Zur Zusammenarbeit lesen Sie auch unseren Leitfaden zum Beitragen auf GitHub.

Wie können Sie bei git pull einen Git Merge Konflikt lösen?

git pull vereint zwei Aufgaben. Zuerst lädt es die Änderungen vom Server, dann führt es sie in Ihren Branch zusammen. Ein Konflikt beim Pull ist also ein gewöhnlicher Merge Konflikt, und Sie gehen genauso vor.

Allerdings führt Pull je nach Einstellung statt eines Merges auch einen Rebase aus. Lesen Sie deshalb die Ausgabe. Steht dort "rebase in progress", brauchen Sie nach der Lösung git rebase --continue. Sonst bringen Sie den Ablauf mit dem falschen Befehl durcheinander.

Zeigt der Pull eine Warnung wie "local changes would be overwritten", ist das ein anderer Fall. Git hat dann schon vor dem Konflikt angehalten. Committen Sie zuerst Ihre Änderungen oder legen Sie sie vorerst per Stash beiseite, und versuchen Sie es danach erneut.

Dazu passt eine sichere Gewohnheit. Zudem sollten Sie vor einem wichtigen Pull git fetch auf und sehen Sie sich git log an. Somit erkennen Sie den Konflikt schon vorher.

Wie unterscheiden sich Stash, Cherry Pick und Revert Konflikte?

Konflikte gibt es allerdings nicht nur bei Merge und Rebase. Jeder Befehl, der Änderungen aus der Historie überträgt, kann einen erzeugen. Die Markierungen sehen zum Beispiel gleich aus. Anders ist, wie Sie abschließen.

• Stash: Gibt es bei git stash pop einen Konflikt, behält Git den gespeicherten Stash. Nach der Lösung löschen Sie ihn dann selbst.
• Cherry Pick: Nach der Lösung nutzen Sie git cherry-pick --continue, zum Aussteigen dann --abort.
• Revert: Dieselbe Logik gilt mit git revert --continue und --abort.

Außerdem nennt die Ausgabe von git status oft, welcher Vorgang offen ist und welcher Befehl als Nächstes kommt. Daher ist Lesen sicherer als Auswendiglernen.

Beispielszenario: Sie haben eine Fehlerbehebung per Cherry Pick auf einen Release Branch übertragen. Die Datei sieht dort anders aus, also gab es einen Konflikt. Richtig ist, den Zweck der Korrektur zu erhalten, ohne den vorhandenen Release Code zu beschädigen.

Wie sehen Sie die drei Versionen einer Konfliktdatei?

Bei einem Konflikt speichert Git eigentlich drei Versionen: den gemeinsamen Vorfahren, Ihre Version und die der anderen Seite. Die Markierungen in der Datei sind eine Mischung daraus. Manchmal wird diese Mischung jedoch unlesbar.

Dann sehen Sie sich jede Version einzeln an. git show :1:dateiname zeigt den Vorfahren, :2: Ihre Seite und :3: die andere Seite. Die Git Dokumentation nennt das Index Stufen. So können Sie alle drei nebeneinander lesen.

Damit beantworten Sie klar, wie die Datei ursprünglich aussah und wer was geändert hat. Vor allem bei großen Dateien und langen Funktionen ersparen Sie sich dadurch viel Zeit.

Kommen Sie zu keinem Ergebnis, verwerfen Sie den Versuch mit git merge --abort. Aktualisieren Sie zuerst Ihren Branch und führen Sie danach in kleineren Teilen erneut zusammen.

Welche kleinen Gewohnheiten erleichtern das Lösen von Konflikten?

Technische Befehle zählen, aber auch Ihre Arbeitsweise. Die folgenden Gewohnheiten erhöhen Tempo und Sicherheit. Zudem braucht keine davon zusätzliche Werkzeuge.

• Legen Sie vor dem Start einen Sicherungsbranch an: git branch sicherung hält den aktuellen Stand fest. Geht etwas schief, haben Sie also einen Rückweg.
• Führen Sie git add direkt aus, wenn eine Datei fertig ist. Dann vergessen Sie nie, welche Datei bereit ist.
• Lösen Sie die Dateien außerdem nacheinander. Drei offene Dateien gleichzeitig erhöhen das Fehlerrisiko.
• Überspringen Sie keine Zeile, die Sie nicht verstehen. Lesen Sie zuerst die Commit Nachricht und fragen Sie bei Bedarf die Autorin oder den Autor.
• Lesen Sie am Ende den Diff noch einmal. Denn eine übersehene Markierung oder die falsche Seite fällt hier auf.

Diese Schritte wirken zwar langsam. Trotzdem sparen sie insgesamt Zeit. Eine falsche Lösung kehrt Tage später als überraschender Fehler zurück, und die Ursache zu finden ist dann viel teurer.

Welche Fehler machen einen Git Konflikt schlimmer?

Weil Gewohnheiten so viel zählen wie technisches Wissen, lohnt sich ein Blick darauf. Das sind die häufigsten Fehler, die wir sehen:

• Die Markierungen zu vergessen und trotzdem zu committen.
• Überall dieselbe Seite zu wählen ("immer meine") und so die Arbeit der anderen zu löschen.
• Die Lösung ohne Test in den Branch zu schicken.
• Einen geteilten Branch ohne Vorwarnung per Rebase umzuschreiben.
• Ein großes Feature wochenlang auf einem Branch zu halten.
• Einen automatischen Formatierer auf einmal über das ganze Projekt laufen zu lassen.

Die meisten davon sind Prozessprobleme und keine Werkzeugprobleme. Kurzlebige Branches, klare Zuständigkeit und ein fester Testschritt lösen den größten Teil.

Beispielszenario: Ein Team aus drei Personen führt am Monatsende alle Branches am selben Tag zusammen. Jeden Monat erleben sie einen anstrengenden Konflikttag. Wechseln sie zu wöchentlichen Merges, werden die Konflikte kleiner und verteilen sich über die Woche. Das ist ein Gedankenbeispiel und keine Messung.

Wann sollten Sie bei einem Git Konflikt Hilfe holen?

Die meisten Konflikte lösen Sie mit den Schritten in diesem Beitrag, denn einen Git Merge Konflikt lösen Sie meist ohne Spezialwissen. Manche Fälle brauchen jedoch eine tiefere Analyse. Zum Beispiel erfordern ein Konflikt auf einem kritischen Produktionsbranch oder eine verworrene Historie besondere Sorgfalt.

Halten Sie zunächst an und notieren Sie den Zustand. Speichern Sie die Ausgabe von git status und den Befehl, den Sie ausgeführt haben. Legen Sie bei Bedarf einen Sicherungsbranch an. Danach entscheiden Sie.

Erzeugen Repository Aufbau, Branch Strategie oder Release Prozess ständig Konflikte, liegt das Problem im Prozess und nicht im Code. Dann müssen Sie Teamablauf und Software Infrastruktur gemeinsam betrachten. Solche Ablaufprobleme gehen wir im Rahmen unserer individuellen Softwareentwicklung an. Ein passendes Angebot können Sie über die Leistungsseite anfordern.

Haben Sie es mit Nachbarfehlern wie SSH Zugriff oder Abhängigkeitsproblemen zu tun, lesen Sie unseren Beitrag zum SSH Fehler Permission denied publickey.