Hi Ich muss zwei Zweige so zusammenführen.
Dies ist nur ein Beispiel, was passiert, ich arbeite mit Hunderten von Dateien, die Auflösung benötigen.
%Vor% Wenn ich git merge tool mache, gibt es den richtigen Inhalt nur aus dem 'ours'-Zweig und wenn ich ihn speichere, verschwindet die Datei aus der nicht zusammengefassten Liste. Aber da ich Hunderte solcher Dateien habe, ist das keine Option.
Ich dachte, dass diese Herangehensweise mich dahin bringen wird, wo ich hin will - einfach sagen, welche Datei von welchem Zweig ich behalten möchte.
Aber ich denke, ich habe das Konzept der git checkout --ours/theirs -Befehle nach einer Zusammenführung falsch verstanden.
Könnten Sie mir bitte einige Informationen geben, wie ich mit dieser Situation umgehen soll? Ich benutze git 1.7.1
Es ist meistens eine Eigenart, wie git checkout intern funktioniert. Die Git-Leute neigen dazu, die Implementierung die Schnittstelle diktieren zu lassen.
Das Endergebnis ist, dass nach git checkout mit --ours oder --theirs , wenn Sie den Konflikt lösen wollen, auch git add die gleichen Pfade haben müssen:
Aber das ist nicht der Fall mit anderen Formen von git checkout :
oder:
%Vor% (diese sind in mehrfacher Hinsicht subtil verschieden). In einigen Fällen ist dies der schnellste Weg, den mittleren Befehl zu verwenden. (Übrigens ist -- hier, um sicherzustellen, dass Git zwischen einem Pfadnamen und einer Option oder einem Verzweigungsnamen unterscheiden kann. Wenn Sie beispielsweise eine Datei namens --theirs haben, sieht diese wie eine Option aus, aber -- wird Git sagen, dass nein, es ist wirklich ein Pfadname.)
Um zu sehen, wie das alles intern funktioniert und warum Sie das separate git add benötigen, außer wenn Sie es nicht tun, lesen Sie weiter. :-) Lassen Sie uns zuerst einen kurzen Überblick über den Zusammenführungsprozess geben.
Beim Ausführen:
$ git merge commit-or-branch
Das erste, was Git tut, ist, die merge base zwischen dem benannten Commit und dem aktuellen ( HEAD ) Commit zu finden. (Beachten Sie, dass Git, wenn Sie hier wie in git merge otherbranch einen Verzweigungsnamen angeben, dies in eine Commit-ID übersetzt, nämlich die Spitze des Zweiges. Er speichert das Argument für den Verzweigungsnamen für die Eventual-Merge-Log-Nachricht, benötigt jedoch das Commit ID, um die Zusammenführungsbasis zu finden.)
Nachdem Sie eine geeignete Zusammenführungsbasis gefunden haben, erzeugt 1 Git zwei git diff -Listen: eins aus der Zusammenführungsbasis nach HEAD und eins aus der Zusammenführungsbasis zu dem von Ihnen angegebenen Commit. Das bekommt "was du verändert hast" und "was sie geändert haben", welches Git nun kombinieren muss.
Für Dateien, bei denen Sie Änderungen vorgenommen haben und die nicht, kann Git einfach Ihre Version übernehmen.
Für Dateien, in denen sie Änderungen vorgenommen haben und die Sie nicht geändert haben, kann Git einfach ihre Version übernehmen.
Bei Dateien, bei denen Sie beide Änderungen vorgenommen haben, muss Git einige echte Zusammenführungsarbeiten durchführen. Es vergleicht die Änderungen zeilenweise, um zu sehen, ob sie sie kombinieren können. Wenn es kann sie kombinieren, tut es dies auch. Wenn die Zusammenführungen wieder auf rein zeilenweisen Vergleichen basieren - auf einen Konflikt, deklariert Git einen "Zusammenführungskonflikt" für diese Datei (und geht weiter und versucht trotzdem zu fusionieren, hinterlässt jedoch Konfliktmarker) / p>
Sobald Git alles zusammengeführt hat, beendet es die Zusammenführung - weil es keine Konflikte gab - oder stoppt mit einem Zusammenführungskonflikt.
1 Die Zusammenführungsbasis ist offensichtlich, wenn Sie das Festschreibungsdiagramm zeichnen. Ohne die Grafik zu zeichnen, ist es irgendwie mysteriös. Deshalb sage ich den Leuten immer, dass sie die Grafik zeichnen sollen, oder zumindest so viel, wie es nötig ist, um einen Sinn zu ergeben.
Die technische Definition besagt, dass die Zusammenführungsbasis der Knoten mit dem "niedrigsten gemeinsamen Vorfahren" (LCA) im Festschreibungsdiagramm ist. Technisch gesehen handelt es sich um den letzten Commit, bei dem sich Ihre aktuelle Zweigstelle mit der Zweigstelle verbindet, die Sie zusammenführen. Das heißt, durch Aufzeichnen der übergeordneten Commit-IDs jeder Zusammenführung kann Git die letzte Zeit finden, in der die beiden Zweige zusammen waren, und somit herausfinden, was Sie getan haben und was sie getan haben. Damit dies überhaupt funktioniert, muss Git jede Zusammenführung aufzeichnen. Insbesondere müssen beide (oder alle für so genannte "Octopus" -Mischungen) Eltern-IDs in das neue Zusammenführungs-Commit geschrieben werden.
In einigen Fällen gibt es mehr als eine geeignete Zusammenführungsbasis. Der Prozess hängt dann von Ihrer Zusammenführungsstrategie ab. Mit der standardmäßigen rekursiven Strategie werden die mehreren Zusammenführungsbasen zusammengeführt, um eine "virtuelle Zusammenführungsbasis" zu erstellen. Dies ist selten genug, dass Sie es für jetzt ignorieren können.
Wenn Git auf diese Weise aufhört, muss es Ihnen die Möglichkeit geben, die Konflikte zu lösen . Aber das bedeutet auch, dass es die Konflikte aufzeichnen muss, und das ist der Punkt, an dem Git "index" - auch "Staging-Bereich" genannt - und manchmal "der Cache" seine Existenz verdient.
Für jede in Ihrem Arbeitsbaum abgelegte Datei enthält der Index bis zu vier Einträge und nicht nur einen Eintrag. Höchstens drei davon werden jemals tatsächlich verwendet, aber es gibt vier Steckplätze, die nummeriert sind, 0 bis 3 .
Slot zero wird für aufgelöste Dateien verwendet. Wenn Sie mit Git arbeiten und keine Zusammenführungen vornehmen, wird only slot zero verwendet. Wenn Sie eine Datei in der Arbeitshierarchie bearbeiten, hat sie "nicht geänderte Änderungen", und dann werden Sie git add die Datei und die Änderungen werden in das Repository geschrieben, wobei der Slot Null aktualisiert wird; Ihre Änderungen sind jetzt "inszeniert".
Die Slots 1-3 werden für nicht aufgelöste Dateien verwendet. Wenn git merge mit einem Zusammenführungskonflikt beendet werden muss, wird der Slot Null leer gelassen und alles auf die Slots 1, 2 und 3 geschrieben. Die merge base Version der Datei wird in Slot 1 aufgezeichnet. Die --ours -Version wird in Slot 2 aufgezeichnet, und die --theirs -Version wird in Slot 3 aufgezeichnet. Bei diesen Nicht-Null-Slot-Einträgen weiß Git, dass die Datei nicht aufgelöst ist. 2
Wenn Sie Dateien auflösen, verwenden Sie git add them, wodurch alle Einträge von Slot 1-3 gelöscht werden und ein Slot-Zero-Eintrag für die Stage-for-Commit-Operation geschrieben wird. Auf diese Weise weiß Git, dass die Datei aufgelöst und für ein neues Commit bereit ist. (Oder, in einigen Fällen, Sie git rm die Datei, in diesem Fall schreibt Git einen speziellen "entfernten" Wert auf Steckplatz Null, wieder Löschen der Steckplätze 1-3.)
2 Es gibt einige Fälle, in denen einer dieser drei Slots ebenfalls leer ist. Angenommen, die Datei new existiert nicht in der Zusammenführungs-Basis und wird sowohl bei uns als auch bei ihnen hinzugefügt. Dann bleibt :1:new leer und :2:new und :3:new zeichnen den add / add Konflikt auf. Oder nehmen wir an, dass Datei f in der Basis vorhanden ist, in unserem HEAD-Zweig geändert wird und in ihrer Verzweigung entfernt wird. Dann zeichnet :1:f die Basisdatei auf, :2:f zeichnet unsere Version der Datei auf und :3:f ist leer und zeichnet den Konflikt zum Ändern / Löschen auf.
Zum Ändern / Ändern von Konflikten sind alle drei Steckplätze belegt; Nur wenn eine Datei fehlt, ist einer dieser Slots leer. Es ist logisch unmöglich, zwei leere Slots zu haben: Es gibt keinen Lösch / Lösch-Konflikt, keinen Nocreate / Add-Konflikt. Aber es gibt etwas Seltsames mit rename Konflikten, die ich hier weggelassen habe, da diese Antwort lang genug ist! In jedem Fall ist es die Existenz einiger Werte in den Steckplätzen 1, 2 und / oder 3, die die Datei als nicht aufgelöst markieren.
Sobald alle Dateien aufgelöst sind - alle Einträge befinden sich nur in den nummerierten Steckplätzen - können Sie git commit das Ergebnis der Zusammenführung angeben. Wenn git merge in der Lage ist, das Zusammenführen ohne Hilfe durchzuführen, führt es normalerweise git commit für Sie aus, aber das eigentliche Festschreiben wird noch ausgeführt, indem Sie git commit ausführen.
Der Commit-Befehl funktioniert auf die gleiche Weise wie immer: Er verwandelt den Indexinhalt in tree -Objekte und schreibt ein neues Commit. Das Besondere an einem Merge-Commit ist, dass es mehr als eine Eltern-Commit-ID hat. 3 Die zusätzlichen Eltern stammen aus einer Datei, die git merge hinterlässt. Die Standard-Merge-Nachricht stammt ebenfalls aus einer Datei (in der Praxis eine separate Datei, obwohl sie im Prinzip auch kombiniert werden könnte).
Beachten Sie, dass der Inhalt des neuen Commits in allen Fällen vom Inhalt des Indexes bestimmt wird. Sobald der neue Commit abgeschlossen ist, ist der Index immer noch voll : Er enthält immer noch den gleichen Inhalt. Standardmäßig erstellt git commit zu diesem Zeitpunkt kein neues Commit, da der Index mit dem HEAD commit übereinstimmt. Es nennt dies "leer" und benötigt --allow-empty , um eine zusätzliche Festschreibung zu machen, aber der Index ist nicht leer . Es ist immer noch voll - es ist nur voll von dem selben Ding wie das HEAD commit.
3 Dies setzt voraus, dass Sie eine echte Zusammenführung, nicht eine Zusammenführung von Squash, vornehmen. Beim Erstellen einer Squash-Zusammenführung schreibt git merge absichtlich nicht die zusätzliche übergeordnete ID in die zusätzliche Datei, so dass die neue Zusammenführungsübereinstimmung nur ein einzelnes übergeordnetes Element aufweist. (Aus irgendeinem Grund unterdrückt git merge --squash auch das automatische Festschreiben, als ob es auch das --no-commit -Flag enthält. Es ist nicht klar warum, denn Sie könnten einfach git merge --squash --no-commit ausführen, wenn Sie will das automatische Commit unterdrückt haben.)
Ein Squash-Merge zeichnet seine anderen Eltern nicht auf. Das heißt, wenn wir erneut zusammenführen, weiß Git später nicht mehr, wo die Diffs von zu starten sind. Dies bedeutet, dass Sie in der Regel nur Squash-Merge durchführen sollten, wenn Sie den anderen Zweig verlassen möchten. (Es gibt einige knifflige Möglichkeiten, Squash-Merges und echte Merges zu kombinieren, aber sie liegen außerhalb des Rahmens dieser Antwort.)
git checkout branch den Index verwendet Nach all dem müssen wir uns ansehen, wie git checkout auch Git's Index benutzt. Denken Sie daran, dass bei normaler Verwendung nur der Steckplatz Null belegt ist und der Index für jede bereitgestellte Datei einen Eintrag enthält. Darüber hinaus stimmt dieser Eintrag mit dem aktuellen ( HEAD ) commit überein, es sei denn, Sie haben die Datei und git add -ed das Ergebnis geändert. Es entspricht auch der Datei in der Arbeitsbaum , wenn Sie die Datei nicht geändert haben. 4
Wenn Sie sich in einer Verzweigung befinden und Ihre git checkout einige andere Verzweigung haben, versucht Git, zur anderen Verzweigung zu wechseln. Damit dies gelingt, muss Git den Indexeintrag für jede Datei durch den Eintrag für den anderen Zweig ersetzen.
Nehmen wir an, Sie befinden sich nur in master und Sie machen git checkout branch . Git vergleicht jeden aktuellen Indexeintrag mit dem Indexeintrag, der auf dem höchstwertigen Commit der Verzweigung branch stehen müsste. Das heißt, für die Datei README.txt sind die master Inhalte die gleichen wie für branch , oder sind sie anders?
Wenn der Inhalt gleich ist, kann Git es leicht nehmen und einfach zur nächsten Datei gehen. Wenn der Inhalt anders ist , muss Git etwas zum Indexeintrag machen. (Um diesen Punkt prüft Git, ob sich die Arbeitsbaumdatei vom Indexeintrag unterscheidet.)
Insbesondere, wenn die Datei branch von master abweicht, muss git checkout ersetzen den Indexeintrag mit der Version von branch -oder if ersetzen README.txt ist nicht vorhanden im Tip-Commit von branch , Git muss den Indexeintrag entfernen . Wenn git checkout den Indexeintrag ändern oder entfernen soll, muss außerdem die Arbeitsbaumdatei geändert oder entfernt werden. Git stellt sicher, dass dies sicher ist, d. H. Dass die Arbeitsbaumdatei mit der master commit-Datei übereinstimmt, bevor Sie die Verzweigungen wechseln können.
Mit anderen Worten, so (und warum) findet Git heraus, ob es in Ordnung ist, Zweige zu wechseln - ob Sie Änderungen haben, die durch den Wechsel von master zu branch verfälscht würden. Wenn Sie Änderungen in Ihrem Arbeitsbaum haben, aber sind die geänderten Dateien in beiden Zweigen gleich, Git kann die Änderungen im Index und in der Arbeitsstruktur einfach beibehalten. Es kann und wird Sie darauf aufmerksam machen, dass diese modifizierten Dateien in den neuen Zweig "übertragen" wurden: einfach, da es ohnehin darauf überprüft werden musste.
Sobald alle Tests bestanden haben und Git entschieden hat, dass es in Ordnung ist, von master zu branch zu wechseln, oder wenn Sie --force angegeben haben - git checkout aktualisiert den Index tatsächlich mit allen geänderten (oder entfernten) Dateien und aktualisiert den entsprechenden Arbeitsbaum.
Beachten Sie, dass diese Aktion den Slot 0 verwendet hat. Es gibt überhaupt keine Slot 1-3 Einträge, so dass git checkout solche Dinge nicht entfernen muss. Sie befinden sich nicht in der Mitte einer konflikthaften Zusammenführung, und Sie haben git checkout branch ausgeführt, um nicht nur eine Datei , sondern eine ganze Menge von Dateien und Zweigverzweigungen auszuchecken .
Beachten Sie auch, dass Sie, anstatt einen Zweig auszuprobieren, einen bestimmten Commit auschecken können. So können Sie beispielsweise einen früheren Commit betrachten:
%Vor% Die Aktion hier ist die gleiche wie beim Auschecken einer Verzweigung, außer dass anstelle des tip Commits der Verzweigung Git eine willkürliche Festschreibung auscheckt. Anstatt jetzt auf dem neuen Zweig "on" zu sein, bist du nun auf no Zweig: 5 Git gibt dir einen "abgetrennten KOPF". Um deinen Kopf wieder zu verbinden, musst du git checkout master oder git checkout branch haben, um "zurück" auf den Zweig zu kommen.
4 Der Indexeintrag stimmt möglicherweise nicht mit der Arbeitsbaumversion überein, wenn Git spezielle Änderungen am CR-LF-Ende durchführt oder Schmierfilter anwendet. Dies wird ziemlich fortgeschritten und das Beste ist, diesen Fall für jetzt zu ignorieren. : -)
5 Genauer gesagt, das bringt Sie in einen anonymen (unbenannten) Zweig, der aus dem aktuellen Commit wachsen wird. Du bleibst im abgetrennten HEAD-Modus, wenn du neue Commits machst, und sobald du git checkout irgendeinen anderen Commit oder Branch hast, wechselst du dorthin und Git wird deine Commits "aufgeben". Der Zweck dieses abgetrennten HEAD-Modus ist es, dich umzusehen und , damit du neue Commits machen kannst, die werden verschwinden, wenn du keine speziellen Aktionen zum Speichern machst Sie. Für jemanden, der relativ neu in Git ist, ist es jedoch nicht so gut, "nur wegzugehen" zu tun - also stellen Sie sicher, dass Sie wissen, dass Sie sich in diesem "abgetrennten KOPF" -Modus befinden, wann immer Sie darin sind.
Der Befehl git status sagt Ihnen, ob Sie sich im abgekoppelten HEAD-Modus befinden. Benutze es oft. 6 Wenn dein Git alt ist (die OPs sind 1.7.1, was jetzt sehr alt ist), ist git status nicht so hilfreich wie in modernen Versionen von Git, aber es ist immer noch besser als nichts.
6 Einige Programmierer möchten die Schlüsselinformationen git status in jede Eingabeaufforderung eingeben. Ich persönlich gehe nicht so weit, aber kann eine gute Idee sein.
Der Befehl git checkout hat jedoch andere Betriebsmodi. Insbesondere können Sie git checkout [flags etc] -- path [path ...] ausführen, um bestimmte Dateien auszuchecken. Hier werden die Dinge komisch. Beachten Sie, dass Git nicht überprüft, ob Sie Ihre Dateien nicht überschreiben, wenn Sie dieses Formular des Befehls verwenden. 7
Statt Äste zu ändern, sagst du Git nun, dass sie bestimmte Dateien von irgendwoher holen und sie in den Arbeitsbaum fallen lassen und überschreiben soll, was auch immer da ist, wenn überhaupt. Die knifflige Frage ist: wo erhält Git gerade diese Dateien?
Im Allgemeinen gibt es drei Orte, an denen Git Dateien behält:
Der Befehl checkout kann von einem der ersten beiden Orte lesen und schreibt das Ergebnis immer in den Arbeitsbaum.
Wenn git checkout eine Datei von einem Commit erhält, wird sie zuerst in den Index kopiert. Immer wenn es dies tut, schreibt es die Datei auf den Steckplatz Null. Schreiben auf Slot Null löscht die Slots 1-3, wenn diese belegt sind. Wenn git checkout eine Datei aus dem Index abruft, muss sie nicht in den Index kopiert werden. (Natürlich nicht: es ist bereits da!) So funktioniert git checkout , wenn Sie nicht mitten in einer Zusammenführung sind: Sie können git checkout -- path/to/file anfordern, um die Indexversion zurück zu bekommen. 9
Angenommen, Sie sind in der Mitte einer konfliktbehafteten Zusammenführung und gehen zu git checkout einiger Pfad, vielleicht mit --ours . (Wenn Sie sich nicht in einer Zusammenführung befinden, gibt es in den Slots 1-3 nichts und --ours macht keinen Sinn.) Sie führen also git checkout --ours -- path/to/file aus.
Dieser git checkout ruft die Datei vom Index ab - in diesem Fall vom Index-Slot 2. Da dies bereits im Index ist, schreibt Git nicht den in Index, nur für die Arbeit -Baum. Also ist die Datei nicht aufgelöst!
Dasselbe gilt für git checkout --theirs : Es ruft die Datei aus dem Index ab (Slot 3) und löst nichts.
Aber : Wenn Sie git checkout HEAD -- path/to/file angeben, geben Sie git checkout an, aus dem HEAD commit zu extrahieren. Da dies ein commit ist, beginnt Git damit, den Inhalt der Datei in den Index zu schreiben. Dies schreibt Slot 0 und löscht 1-3. Und jetzt ist die Datei aufgelöst!
Da Git während einer konflikthaften Zusammenführung die ID des mischenden Commits in MERGE_HEAD aufzeichnet, können Sie auch git checkout MERGE_HEAD -- path/to/file verwenden, um die Datei von dem anderen Commit zu erhalten. Auch dies wird aus einem Commit extrahiert, sodass es in den Index schreibt und die Datei auflöst.
7 Ich möchte oft, dass Git einen anderen Front-End-Befehl dafür verwendet, da wir dann eindeutig sagen können, dass der Git-Checkout sicher ist, dass er keine Dateien ohne --force überschreibt. . Aber diese Art von git checkout überschreibt Dateien mit Absicht!
8 Das ist eine Lüge oder zumindest eine Dehnung: Commits enthalten keine Dateien direkt. Stattdessen enthalten commits einen (einzelnen) Zeiger auf ein tree -Objekt. Dieses Baumobjekt enthält die IDs zusätzlicher Baumobjekte und von Blob Objekten. Die Blob-Objekte enthalten den eigentlichen Dateiinhalt.
Das gilt auch für den Index. Jeder Index-Slot enthält nicht die eigentliche Datei contents , sondern die Hash-IDs von Blob-Objekten im Repository.
Für unsere Zwecke ist das jedoch nicht wirklich wichtig: Wir fragen Git einfach nach commit:path und es findet die Bäume und die Blob-ID für uns. Oder wir fragen Git nach :n:path und es findet die Blob-ID im Indexeintrag für path für Slot n . Dann bekommen wir den Inhalt der Datei und wir können loslegen.
Diese Doppelpunkt-und-Nummer-Syntax funktioniert überall in Git, während die Flags --ours und --theirs nur in git checkout funktionieren. Die lustige Kolon-Syntax wird in gitrevisions beschrieben.
9 Der Anwendungsfall für git checkout -- path ist folgender: Angenommen, Sie führen ein paar Änderungen an einer Datei durch, testen diese, haben festgestellt, dass diese Änderungen funktionieren, und dann% co_de ausgeführt % für die Datei. Dann haben Sie sich entschieden, weitere Änderungen vorzunehmen, aber% code_% nicht erneut ausgeführt. Sie testen die zweite Gruppe von Änderungen und finden sie falsch. Wenn du nur die Arbeitsbaum-Version der Datei zurück auf die Version bekommen könntest, die du vor einem Moment git add -edest ... Aha, du kannst : du git add und Git kopiert die Indexversion von Steckplatz 0 zurück in den Arbeitsbaum.
Beachten Sie jedoch, dass die Verwendung von git add oder git checkout -- path neben dem Verhalten "Aus Index extrahieren und daher nicht auflösen" einen weiteren kleinen Unterschied aufweist. Nehmen wir an, dass Git in unserer Konfliktverschmelzung festgestellt hat, dass eine Datei umbenannt wurde . Das heißt, in der Zusammenführungsbasis hatten wir die Datei --ours , aber jetzt haben wir in --theirs doc.txt . Der Pfad, den wir für HEAD benötigen, ist Documentation/doc.txt . Dies ist auch der Pfad im git checkout --ours commit, also ist es in Ordnung, Documentation/doc.txt .
Aber was wäre, wenn HEAD nicht beim Commit, das wir zusammenführen, umbenannt wird? In diesem Fall sollten wir 10 in der Lage sein, git checkout HEAD -- Documentation/doc.txt ihre doc.txt aus dem Index zu erhalten. Aber wenn wir git checkout --theirs -- Documentation/doc.txt versuchen, wird Git die Datei nicht finden können: es ist nicht in doc.txt , in git checkout MERGE_HEAD -- Documentation/doc.txt commit. Wir müssen Documentation haben, um ihre Datei zu erhalten ... und das würde nicht MERGE_HEAD auflösen. In der Tat würde es nur git checkout MERGE_HEAD -- doc.txt erstellen (wenn es umbenannt wurde, gibt es fast sicher keine Documentation/doc.txt , daher ist "create" eine bessere Schätzung als "overwrite").
Da beim Zusammenführen die Namen von ./doc.txt verwendet werden, ist es in der Regel sicher genug, ./doc.txt in einem Schritt zu extrahieren und aufzulösen. Und wenn Sie an der Auflösung von Dateien arbeiten und HEAD ausgeführt haben, sollten Sie wissen, ob sie eine umbenannte Datei haben und ob git checkout HEAD -- path in einem Schritt extrahiert und aufgelöst werden kann, indem Sie Ihre eigenen Änderungen verwerfen . Aber Sie sollten sich dessen bewusst sein und wissen, was zu tun ist, wenn ein Umbenennen ist, mit dem Sie sich befassen müssen.
10 Ich sage "sollte" hier, nicht "kann", weil Git momentan das Umbenennen etwas zu früh vergisst. Wenn Sie also git status verwenden, um eine Datei zu erhalten, die Sie in git checkout MERGE_HEAD -- path umbenannt haben, müssen Sie auch hier den alten Namen verwenden und dann die Datei im Arbeitsbaum umbenennen.
Tags und Links git git-branch repository git-merge git-checkout