Warum kann git keine Hard / Soft-Resets nach Pfad durchführen?

$ git reset -- <file_path> kann über Pfad zurückgesetzt werden.

Es wird jedoch $ git reset (--hard|--soft) <file_path>ein Fehler wie folgt gemeldet:

Cannot do hard|soft reset with paths.

Weil es keinen Sinn macht (andere Befehle bieten diese Funktionalität bereits an) und es das Risiko verringert, versehentlich das Falsche zu tun.

Ein "Hard Reset" für einen Pfad wird gerade durchgeführt git checkout HEAD -- <path>(Auschecken der vorhandenen Version der Datei).

Ein Soft-Reset für einen Pfad macht keinen Sinn.

Ein gemischter Reset für einen Pfad ist das, was git reset -- <path>bewirkt.

Sie können das erreichen, was Sie damit versuchen git checkout HEAD <path>.

Die bereitgestellte Fehlermeldung macht für mich jedoch keinen Sinn (da sie git resetin Unterverzeichnissen einwandfrei funktioniert), und ich sehe keinen Grund, warum Sie git reset --hardnicht genau das tun sollten, was Sie von ihr verlangen.

Die Frage wie wird schon beantwortet , ich erkläre den Warum- Teil.

Also, was macht Git Reset ? Abhängig von den angegebenen Parametern kann es zwei verschiedene Dinge tun:

• Wenn Sie einen Pfad angeben, werden die übereinstimmenden Dateien im Index durch die Dateien aus einem Commit ersetzt (standardmäßig HEAD). Diese Aktion wirkt sich überhaupt nicht auf den Arbeitsbaum aus und wird normalerweise als Gegenteil von git add verwendet.

• Wenn Sie keinen Pfad angeben, wird der aktuelle Verzweigungskopf in ein bestimmtes Commit verschoben und zusammen mit diesem optional der Index und der Arbeitsbaum auf den Status dieses Commits zurückgesetzt. Dieses zusätzliche Verhalten wird durch den Parameter mode gesteuert:
  --soft : Berühren Sie nicht den Index und den Arbeitsbaum.
  --mixed (Standard): Setzt den Index zurück, aber nicht den Arbeitsbaum.
  --hard : Index und Arbeitsbaum zurücksetzen.
  Es gibt auch andere Optionen. Die vollständige Liste und einige Anwendungsfälle finden Sie in der Dokumentation.

  Wenn Sie kein Commit angeben, wird standardmäßig HEAD verwendet, sodass git reset --softnichts unternommen wird, da es sich um einen Befehl handelt, den Kopf in HEAD (in den aktuellen Status) zu verschieben. git reset --hardAuf der anderen Seite ist es aufgrund seiner Nebenwirkungen sinnvoll , den Kopf auf HEAD zu bewegen und den Index und den Arbeitsbaum auf HEAD zurückzusetzen.

  Ich denke, es sollte jetzt klar sein, warum dieser Vorgang von Natur aus nicht für bestimmte Dateien gilt - er soll in erster Linie einen Verzweigungskopf verschieben, den Arbeitsbaum zurücksetzen und der Index ist eine sekundäre Funktionalität.

Stellen Sie sicher, dass Sie einen Schrägstrich zwischen Ursprung oder Upstream (Quelle) und dem tatsächlichen Zweig setzen:

git reset --hard origin/branch

oder

git reset --hard upstream/branch`

Dahinter steckt ein sehr wichtiger Grund: die Prinzipien von checkoutundreset .

In Git-Begriffen bedeutet Auschecken "In den aktuellen Arbeitsbaum bringen". Und mit können git checkoutwir den Arbeitsbaum mit Daten aus jedem Bereich füllen , sei es aus einem Commit im Repository oder aus einzelnen Dateien aus einem Commit oder dem Staging-Bereich (dies ist sogar die Standardeinstellung).

Git Reset hat diese Rolle wiederum nicht. Wie der Name schon sagt, wird die aktuelle Referenz zurückgesetzt, wobei jedoch immer das Repository als Quelle verwendet wird, unabhängig von der "Reichweite" (--soft, --mixed oder --hard).

Rekapitulieren:

• Kasse : Von überall (Index / Repo-Commit) -> Arbeitsbaum
• Zurücksetzen : Repo-Commit -> HEAD überschreiben (und optional Index und Arbeitsbaum)

Was daher etwas verwirrend sein kann, ist die Existenz von git reset COMMIT -- files"Überschreiben von HEAD" mit nur einigen Dateien macht keinen Sinn!

In Ermangelung einer offiziellen Erklärung kann ich nur spekulieren, dass die Git-Entwickler festgestellt haben, dass dies resetimmer noch der beste Name für einen Befehl zum Verwerfen von Änderungen ist, die am Staging-Bereich vorgenommen wurden, und angesichts der einzigen Datenquelle, die das Repository war, "erweitern wir das Funktionalität "anstatt einen neuen Befehl zu erstellen.

Irgendwie git reset -- <files>ist das schon ein bisschen außergewöhnlich: Es wird den KOPF nicht überschreiben. IMHO wären alle diese Variationen Ausnahmen. Selbst wenn wir uns eine --hardVersion vorstellen können , --softwären andere (zum Beispiel ) nicht sinnvoll.

Erläuterung

Das git resetHandbuch listet drei Arten des Aufrufs auf:

• 2 sind dateiweise: Diese wirken sich nicht auf den Arbeitsbaum aus , sondern wirken sich nur auf die Dateien in dem Index aus, der durch Folgendes angegeben ist <paths>:

  • git reset [-q] [<tree-ish>] [--] <paths>..
  • git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]

• 1 ist Commit-weise: Funktioniert mit allen Dateien in der referenzierten Datei<commit> und kann sich auf den Arbeitsbaum auswirken:

  • git reset [<mode>] [<commit>]

Es gibt keinen Aufrufmodus, der nur für bestimmte Dateien gilt und sich auf den Arbeitsbaum auswirkt.

Problemumgehung

Wenn Sie beides wollen:

• Setzen Sie die Index- / Cache-Version einer Datei zurück.
• Überprüfen Sie die Datei (en) (dh lassen Sie den Arbeitsbaum mit dem Index und der Commit-Version übereinstimmen).

Sie können diesen Alias ​​in Ihrer Git-Konfigurationsdatei verwenden:

[alias]
  reco   = !"cd \"${GIT_PREFIX:-.}\" && git reset \"$@\" && git checkout \"$@\" && git status --short #"  # Avoid: "fatal: Cannot do hard reset with paths."

Sie können dann einen der folgenden Schritte ausführen:

$ git reco <paths>

$ git reco <branch/commit> <paths>

$ git reco -- <paths>

(Mnenonic für reco: reset && check out)

git reset --soft HEAD ~ 1 Dateiname macht das Commit rückgängig, aber die Änderungen bleiben lokal. Dateiname könnte sein - für alle festgeschriebenen Dateien