English ▾ Themen ▾ Neueste Version ▾ git-rerere zuletzt aktualisiert in 2.39.0

NAME

git-rerere - Aufzeichnen und Wiederverwenden von Konfliktlösungen

SYNOPSIS

git rerere [clear | forget <pathspec>…​ | diff | status | remaining | gc]

BESCHREIBUNG

In einem Workflow, der relativ lang laufende Thema-Branches verwendet, muss der Entwickler manchmal immer wieder dieselben Konflikte lösen, bis die Thema-Branches fertig sind (entweder in den "Release"-Branch gemergt oder an upstream gesendet und akzeptiert).

Dieser Befehl unterstützt den Entwickler bei diesem Prozess, indem er die Ergebnisse von automatischen Merge-Konflikten und die entsprechenden manuellen Auflösungen beim ersten manuellen Merge aufzeichnet und zuvor aufgezeichnete manuelle Auflösungen auf ihre entsprechenden automatischen Merge-Ergebnisse anwendet.

Hinweis
 Sie müssen die Konfigurationsvariable rerere.enabled setzen, um diesen Befehl zu aktivieren.

BEFEHLE

Normalerweise wird git rerere ohne Argumente oder Benutzerintervention aufgerufen. Es gibt jedoch mehrere Befehle, die es ihm ermöglichen, mit seinem Arbeitszustand zu interagieren.

clear

Setzt die von rerere verwendeten Metadaten zurück, wenn eine Merge-Auflösung abgebrochen werden soll. Der Aufruf von git am [--skip|--abort] oder git rebase [--skip|--abort] ruft diesen Befehl automatisch auf.

forget <pathspec>

Setzt die von rerere aufgezeichneten Konfliktlösungen für den aktuellen Konflikt in <pathspec> zurück.

diff

Zeigt Unterschiede für den aktuellen Zustand der Auflösung an. Dies ist nützlich, um zu verfolgen, was sich geändert hat, während der Benutzer Konflikte löst. Zusätzliche Argumente werden direkt an den im PATH installierten System-diff-Befehl übergeben.

status

Gibt Pfade mit Konflikten aus, deren Merge-Auflösung rerere aufzeichnen wird.

remaining

Gibt Pfade mit Konflikten aus, die nicht von rerere automatisch aufgelöst wurden. Dazu gehören Pfade, deren Auflösungen nicht von rerere verfolgt werden können, wie z. B. kollidierende Submodule.

gc

Bereinigt Aufzeichnungen von Konflikt-Merges, die vor langer Zeit aufgetreten sind. Standardmäßig werden ungelöste Konflikte, die älter als 15 Tage sind, und gelöste Konflikte, die älter als 60 Tage sind, bereinigt. Diese Standardwerte werden über die Konfigurationsvariablen gc.rerereUnresolved und gc.rerereResolved gesteuert.

DISKUSSION

Wenn Ihr Thema-Branch einen überlappenden Bereich modifiziert, den Ihr Master-Branch (oder Upstream) seit dem Fork Ihres Thema-Branches von ihm berührt hat, möchten Sie ihn möglicherweise mit dem neuesten Master testen, noch bevor Ihr Thema-Branch bereit zum Pushen an Upstream ist.

              o---*---o topic
             /
    o---o---o---*---o---o master

Für einen solchen Test müssen Sie Master und Thema irgendwie zusammenführen. Eine Möglichkeit, dies zu tun, ist, Master in den Thema-Branch zu ziehen

	$ git switch topic
	$ git merge master

              o---*---o---+ topic
             /           /
    o---o---o---*---o---o master

Die mit * markierten Commits berühren denselben Bereich in derselben Datei; Sie müssen die Konflikte lösen, wenn Sie den mit + markierten Commit erstellen. Dann können Sie das Ergebnis testen, um sicherzustellen, dass Ihre Arbeit im Gange immer noch mit dem neuesten Master übereinstimmt.

Nach diesem Test-Merge gibt es zwei Möglichkeiten, Ihre Arbeit am Thema fortzusetzen. Die einfachste ist, auf dem Test-Merge-Commit + aufzubauen, und wenn Ihre Arbeit im Thema-Branch endlich fertig ist, ziehen Sie den Thema-Branch in den Master und/oder bitten Sie Upstream, von Ihnen zu ziehen. Bis dahin könnten der Master oder Upstream jedoch seit dem Test-Merge + fortgeschritten sein, in diesem Fall würde der endgültige Commit-Graph so aussehen:

	$ git switch topic
	$ git merge master
	$ ... work on both topic and master branches
	$ git switch master
	$ git merge topic

              o---*---o---+---o---o topic
             /           /         \
    o---o---o---*---o---o---o---o---+ master

Wenn Ihr Thema-Branch lang läuft, hätte Ihr Thema-Branch am Ende viele solche "Merge von Master"-Commits, die die Entwicklungshistorie unnötig verunreinigen würden. Leser der Linux-Kernel-Mailingliste erinnern sich vielleicht, dass Linus sich über so häufige Test-Merges beschwerte, als ein Subsystem-Maintainer darum bat, von einem Branch voller "nutzloser Merges" zu ziehen.

Alternativ können Sie, um den Thema-Branch frei von Test-Merges zu halten, den Test-Merge löschen und weiter auf der Spitze vor dem Test-Merge aufbauen.

	$ git switch topic
	$ git merge master
	$ git reset --hard HEAD^ ;# rewind the test merge
	$ ... work on both topic and master branches
	$ git switch master
	$ git merge topic

              o---*---o-------o---o topic
             /                     \
    o---o---o---*---o---o---o---o---+ master

Dies würde nur einen Merge-Commit hinterlassen, wenn Ihr Thema-Branch endlich fertig ist und in den Master-Branch gemergt wird. Dieser Merge würde erfordern, dass Sie den Konflikt lösen, der durch die mit * markierten Commits eingeführt wurde. Dieser Konflikt ist jedoch oft derselbe Konflikt, den Sie gelöst haben, als Sie den Test-Merge erstellt haben, den Sie gelöscht haben. git rerere hilft Ihnen, diesen endgültigen konfliktbehafteten Merge anhand der Informationen aus Ihrer früheren manuellen Auflösung zu lösen.

Das Ausführen des Befehls git rerere unmittelbar nach einem automatischen Konflikt-Merge zeichnet die kollidierenden Arbeitsbaumdateien mit den üblichen Konfliktmarkern <<<<<<<, ======= und >>>>>>> darin auf. Später, nachdem Sie die Konflikte gelöst haben, zeichnet das erneute Ausführen von git rerere den gelösten Zustand dieser Dateien auf. Angenommen, Sie haben dies getan, als Sie den Test-Merge von Master in den Thema-Branch erstellt haben.

Beim nächsten Mal, nachdem Sie denselben automatischen Konflikt-Merge gesehen haben, führt das Ausführen von git rerere einen Drei-Wege-Merge zwischen dem früheren automatischen Konflikt-Merge, der früheren manuellen Auflösung und dem aktuellen automatischen Konflikt-Merge durch. Wenn dieser Drei-Wege-Merge sauber gelöst wird, wird das Ergebnis in Ihre Arbeitsbaumdatei geschrieben, sodass Sie es nicht manuell lösen müssen. Beachten Sie, dass git rerere die Indexdatei unverändert lässt, sodass Sie die endgültigen Überprüfungen mit git diff (oder git diff -c) und git add durchführen müssen, wenn Sie zufrieden sind.

Als Komfortfunktion ruft git merge automatisch git rerere auf, wenn es mit einem fehlgeschlagenen automatischen Merge beendet wird, und git rerere zeichnet die manuelle Auflösung auf, wenn es sich um einen neuen Konflikt handelt, oder verwendet die frühere manuelle Auflösung wieder, wenn es keiner ist. git commit ruft ebenfalls git rerere auf, wenn ein Merge-Ergebnis committet wird. Das bedeutet, dass Sie selbst nichts Besonderes tun müssen (abgesehen vom Aktivieren der Konfigurationsvariable rerere.enabled).

In unserem Beispiel wird bei der Durchführung des Test-Merges die manuelle Auflösung aufgezeichnet und wiederverwendet, wenn Sie später den tatsächlichen Merge mit dem aktualisierten Master und Thema-Branch durchführen, solange die aufgezeichnete Auflösung noch anwendbar ist.

Die von git rerere aufgezeichneten Informationen werden auch beim Ausführen von git rebase verwendet. Nachdem Sie den Test-Merge gelöscht und die Entwicklung auf dem Thema-Branch fortgesetzt haben

              o---*---o-------o---o topic
             /
    o---o---o---*---o---o---o---o   master

	$ git rebase master topic

				  o---*---o-------o---o topic
				 /
    o---o---o---*---o---o---o---o   master

Sie könnten git rebase master topic ausführen, um auf den neuesten Stand zu kommen, bevor Ihr Thema bereit ist, an Upstream gesendet zu werden. Dies würde dazu führen, dass auf einen Drei-Wege-Merge zurückgegriffen wird, und es würde auf dieselbe Weise zu Konflikten kommen wie beim Test-Merge, den Sie zuvor gelöst haben. git rerere wird von git rebase aufgerufen, um Ihnen bei der Lösung dieses Konflikts zu helfen.

[HINWEIS] git rerere verlässt sich auf die Konfliktmarker in der Datei, um den Konflikt zu erkennen. Wenn die Datei bereits Zeilen enthält, die genauso aussehen wie Zeilen mit Konfliktmarkern, kann git rerere möglicherweise keine Konfliktlösung aufzeichnen. Um dies zu umgehen, kann die Einstellung conflict-marker-size in gitattributes[5] verwendet werden.

GIT

Teil der git[1] Suite