Was ist der Unterschied zwischen git reset --mixed, --soft und -hard?

Question

Ich möchte eine Übertragung aufteilen und bin mir nicht sicher, welche Rücksetzoption ich verwenden soll.

Ich habe mir die Seite angesehen Was bedeutet "git reset" im Klartext? aber ich habe gemerkt, dass ich nicht wirklich verstehe, was der Git-Index oder der Staging-Bereich ist, und daher waren die Erklärungen nicht hilfreich.

Auch die Anwendungsfälle für --mixed y --soft sehen für mich in dieser Antwort gleich aus (wenn Sie die Sache in Ordnung bringen und erneut in Angriff nehmen wollen). Kann das jemand noch weiter aufschlüsseln? Mir ist klar --mixed ist wahrscheinlich die beste Lösung, aber ich möchte wissen warum . Und schließlich, was ist mit --hard ?

Kann mir jemand ein Beispiel für einen Arbeitsablauf geben, wie die Auswahl der 3 Optionen erfolgen würde?

Answer 1

Wenn Sie eine Datei in Ihrem Repository ändern, wird die Änderung zunächst nicht übertragen. Um sie zu übertragen, müssen Sie sie in den Index aufnehmen, indem Sie git add . Wenn Sie eine Übertragung vornehmen, werden die Änderungen übertragen, die dem Index hinzugefügt wurden.

git reset ändert zumindest, wo der aktuelle Zweig ( HEAD ) zeigt. Der Unterschied zwischen --mixed y --soft ist, ob Ihr Index ebenfalls geändert wird oder nicht. Wenn wir also im Zweig master mit dieser Reihe von Übertragungen:

- A - B - C (master)

HEAD zeigt auf C und der Index entspricht C .

Wenn wir die git reset --soft B , master (und damit HEAD ) zeigt nun auf B aber der Index enthält noch die Änderungen von C ; git status werden sie als inszeniert dargestellt. Wenn wir also Folgendes ausführen git commit erhalten wir eine neue Übertragung mit denselben Änderungen wie C .

---

Okay, also noch einmal von vorne:

- A - B - C (master)

Jetzt machen wir git reset --mixed B . (Anmerkung: --mixed ist die Standardoption). Noch einmal, master y HEAD auf B zeigen, aber dieses Mal wird der Index auch geändert, um mit B . Wenn wir die git commit zu diesem Zeitpunkt wird nichts passieren, da der Index mit HEAD . Wir haben die Änderungen immer noch im Arbeitsverzeichnis, aber da sie nicht im Index sind, git status zeigt sie als nicht inszeniert. Um sie zu übertragen, müssen Sie git add und dann wie gewohnt übertragen.

---

Und schließlich, --hard ist dasselbe wie --mixed (es verändert Ihre HEAD und Index), mit der Ausnahme, dass --hard ändert auch Ihr Arbeitsverzeichnis. Wenn wir uns bei C und laufen git reset --hard B und dann die Änderungen in C sowie alle nicht übertragenen Änderungen werden entfernt, und die Dateien in Ihrer Arbeitskopie werden mit der Übertragung B . Da Sie auf diese Weise Änderungen dauerhaft verlieren können, sollten Sie immer git status bevor Sie einen Hard-Reset durchführen, um sicherzustellen, dass Ihr Arbeitsverzeichnis sauber ist oder dass Sie damit einverstanden sind, Ihre nicht übertragenen Änderungen zu verlieren.

---

Und schließlich eine Visualisierung:

Answer 2

Vereinfacht ausgedrückt:

• --soft : freigeben Änderungen, werden Änderungen stufenweise belassen ( Index ).
• --mixed (Standard) : uncommit + unstage Änderungen, werden Änderungen in Arbeitsbaum .
• --hard : uncommit + unstage + delete Veränderungen, nichts mehr.

Answer 3

Drei Arten des Bedauerns

Viele der vorhandenen Antworten scheinen nicht auf die eigentliche Frage einzugehen. Es geht darum, was die Befehle tun, und nicht darum, was Sie (der Benutzer) wollen - die Anwendungsfall . Aber das ist es, wonach der Auftraggeber gefragt hat!

Es könnte hilfreicher sein, die Beschreibung so zu formulieren, dass sie genau das beschreibt, was Sie Bedauern zu dem Zeitpunkt, zu dem Sie eine git reset Befehl. Nehmen wir an, wir haben dies:

A - B - C - D <- HEAD

Im Folgenden finden Sie einige mögliche Bedauernsfälle und was Sie dagegen tun können:

1. Ich bedauere, dass B, C und D nicht eine verpflichten.

git reset --soft A . Jetzt kann ich sofort übertragen und schon sind alle Änderungen seit A sont eine Verpflichtung.

2. Ich bedauere, dass B, C und D nicht zwei Commits (oder zehn Commits, oder was auch immer).

git reset --mixed A . Die Commits sind weg und der Index ist wieder bei A, aber der Arbeitsbereich sieht immer noch so aus wie nach D. Jetzt kann ich also in einer ganz anderen Gruppierung hinzufügen und committen.

3. Ich bedauere, dass B, C und D passiert sind in dieser Branche Ich wünschte, ich wäre nach A abgezweigt und sie wären auf dem anderen Ast passiert.

Einen neuen Zweig erstellen otherbranch und dann git reset --hard A . Der aktuelle Zweig endet nun bei A, mit otherbranch die sich daraus ableitet und B, C und D enthält.

(Natürlich können Sie auch einen Hard-Reset durchführen, weil Sie sich wünschen, dass B, C und D nie passiert wären).

Answer 4

Bitte beachten Sie, dass es sich hierbei um eine vereinfachte Erklärung handelt, die als erster Schritt zum Verständnis dieser komplexen Funktion gedacht ist.

Dies kann für visuelle Lernende hilfreich sein, die sich ein Bild davon machen wollen, wie ihr Projektstatus nach jedem dieser Befehle aussieht:

Gegeben: - A - B - C (master)

---

Für diejenigen, die Terminal mit eingeschalteter Farbe verwenden (git config --global color.ui auto):

git reset --soft A und Sie werden die Sachen von B und C in grün sehen (vorbereitet und bereit zur Übergabe)

git reset --mixed A (oder git reset A ) und Sie werden die Sachen von B und C in rot sehen (unstaged und bereit für staged (grün) und dann committed)

git reset --hard A und Sie werden die Änderungen von B und C nirgendwo mehr sehen (als ob sie nie existiert hätten)

---

Oder für diejenigen, die ein GUI-Programm wie 'Tower' oder 'SourceTree' verwenden

git reset --soft A und Sie werden die Sachen von B und C im Bereich 'staged files' sehen, bereit zum Übertragen

git reset --mixed A (oder git reset A ) und Sie werden die Dateien von B und C im Bereich "Unstaged Files" sehen, die bereit sind, in den Staged-Bereich verschoben und dann übertragen zu werden

git reset --hard A und Sie werden die Änderungen von B und C nirgendwo mehr sehen (als ob sie nie existiert hätten)

Answer 5

Alle anderen Antworten sind großartig, aber ich finde, man versteht sie am besten, wenn man die Dateien in drei Kategorien unterteilt: unstaged , staged , commit :

• --hard sollte einfach zu verstehen sein, es stellt alles wieder her
• --mixed (Standard) :
  1. unstaged Dateien: sich nicht ändern
  2. staged Dateien: Verschieben nach unstaged
  3. commit Dateien: Verschieben nach unstaged
• --soft :
  1. unstaged Dateien: sich nicht ändern
  2. staged Dateien: sich nicht ändern
  3. commit Dateien: Verschieben nach staged

Zusammengefasst:

• --soft verschiebt alles (außer unstaged Dateien) in staging area
• --mixed verschiebt alles nach unstaged area