Den Konflikt erzeugen
Führe diese Bash-Übung in einem neuen, leeren Verzeichnis aus. Die Branch-Namen und die Datei gehören nur zu diesem Beispiel.
git init -b main
git config user.name "DevSheet Demo"
git config user.email "demo@example.invalid"
printf "colour=blue\n" > settings.txt
git add settings.txt
git commit -m "Base colour"
git switch -c feature
printf "colour=green\n" > settings.txt
git commit -am "Feature colour"
git switch main
printf "colour=red\n" > settings.txt
git commit -am "Main colour"
git merge featureDer letzte Befehl soll mit einem Konflikt in settings.txt anhalten. Ein Exit-Code ungleich null ist hier erwartet.
Beide Versionen lesen
git status --short
git diff -- settings.txtAchte auf UU settings.txt. <<<<<<< HEAD beginnt den Inhalt des aktuellen Branches, ======= trennt die Versionen und >>>>>>> feature beendet die eingehende Version. Diese Markierungen gelten für einen normalen Merge; beim Rebase ist der Zusammenhang anders.
Endgültigen Inhalt schreiben und prüfen
Wähle in dieser Übung Grün. Ersetze die gesamte Konfliktdatei, füge nur diese Datei zum Index hinzu und prüfe den Diff.
printf "colour=green\n" > settings.txt
git add settings.txt
git diff --cached
git merge --continue
git status --shortSpeichere die Merge-Nachricht im Editor. Erwartet werden ein sauberer Status und ein Merge-Commit. In einem echten Projekt kombinierst du die Änderungen passend zum gewünschten Verhalten und führst die relevanten Prüfungen vor dem Abschluss aus.
Einen blockierten Merge abbrechen oder prüfen
Bei einem ungelösten Konflikt versucht git merge --abort, den vorherigen Zustand wiederherzustellen. Committe oder stashe unabhängige Arbeit vorher; vorhandene Änderungen lassen sich beim Abbruch möglicherweise nicht vollständig rekonstruieren.
Das Hinzufügen zum Index erklärt eine Datei für gelöst, auch wenn Konfliktmarker verbleiben. Lies den Diff. Binärdateien, Lösch-/Änderungskonflikte und Umbenennungen brauchen eigene Entscheidungen.