Was ist der Zweck von git stash, wenn Sie nur ein neues Commit durchführen können?

Sie haben Recht, dass Sie einfach ein Commit durchführen können (und später zurückkommen und git reset --softdas Commit aufheben können), und das mache ich manchmal, wenn ich neu festlege.

Springt es Sie bei Verwendung git stash popautomatisch zurück zu dem Zweig, den Sie versteckt haben? Was wäre, wenn ich für jeden Zweig einen anderen Vorrat erstellen wollte?

Es tut nicht. (Ich sehe, dass jemand die stash@{N}Notation bereits erwähnt hat, daher werde ich dies aus dieser Antwort herauslassen, außer um hinzuzufügen, dass dies Git's Reflogs verwendet.) Das Anwenden des Stashs ist meistens, wenn auch nicht vollständig, wie das Verwenden git showoder git log -pKonvertieren eines Commits in einen Patch. dann den Patch mit anwenden git apply.

Ein Stash wird als zwei oder drei ^1- Commits gespeichert , die sich in keinem Zweig befinden. Ich nenne diese Commits aus mehreren Gründen gerne einen "Stash Bag". Einer davon ist, dass der Beutel von dem spezifischen Commit abhängt, der aktuell war, als Sie den Stash erstellt haben.

Wenn wir eine Reihe von normalen (nicht zusammengeführten) Commits als eine Linie von Knoten ozeichnen, von denen jeder auf das übergeordnete Element zeigt, und dann den Zweignamen als Zeiger zeichnen, der das Spitzen-Commit des Zweigs identifiziert, erhalten wir eine schöne kompakte Darstellung eines Teils des Commit-Diagramms:

... <- o <-o <- o   <-- branch

Normalerweise lassen wir die internen Pfeile einfach weg, da wir wissen, dass jedes Commit auf sein übergeordnetes Element verweist:

...--o--o--o   <-- branch

Wenn Sie an dieser Stelle einen Stash erstellen, hängen zwei ² Commits vom Tip Commit ab. Eine davon, die eine, die ich beschrifte i, ist der Indexstatus (was Sie bearbeitet haben git add), und die andere wist der Arbeitsbaumstatus (alle nachverfolgten Dateien im Arbeitsbaum, die Sie hätten bearbeiten können git add):

...--o--o--o   <-- branch
           |\
           i-w <-- stash

Diese Aufbewahrungstasche hängt einfach da, baumelt fröhlich davon und wird über die spezielle stashReferenz gefunden. Denn es wird über gefunden stash, wenn Sie laufen git log --alloder gitk --alloder ähnliches, werden Sie es sehen.

Wenn Sie dann Ihren Zweig neu gründen , kopiert Git die Commits auf dem Zweig zurück zu einem beliebigen Punkt. Das heißt, das "Vorher" -Diagramm wird genauer wie folgt gezeichnet:

...--o--o--o--o--o--o  <-- feature
      \
       \
        \
         o--o--o       <-- branch
               |\
               i-w     <-- stash

Rebasing branchauf featuremacht neue Kopien der alten Commits und bewegt sich das Etikett:

...--o--o--o--o--o--o  <-- feature
      \              \
       \              o--o--o   <-- branch
        \
         o--o--o       [abandoned: previous branch]
               |\
               i-w     <-- stash

Beachten Sie, dass Sie beim Ausführen von git log --alloder gitk --allnormalerweise Ihren ursprünglichen Zweig und seine drei Commits nicht mehr sehen würden. Da stashjedoch immer noch darauf hingewiesen wird w, werden jetzt nicht nur die Verstecke, sondern auch die ursprünglichen drei Commits angezeigt.

Laufen - git stash popIch schlage vor, bei git stash apply^{3 zu} bleiben, bis Sie mit Stashes und Git im Allgemeinen wirklich vertraut sind, da applySie die Möglichkeit haben, Ihre Meinung zu ändern, aber lassen Sie uns überlegen - poplässt Git den Stash auf Ihr neues aktuelles Commit anwenden (wahrscheinlich das neue Spitze der kopierten branch) und lassen Sie dann die stashReferenz fallen:

...--o--o--o--o--o--o  <-- feature
      \              \
       \              o--o--o   <-- branch
        \
         o--o--o       [abandoned: previous branch]
               |\
               i-w     [abandoned]

und jetzt tauchen all diese alten Verpflichtungen zusammen mit dem Vorrat nicht mehr auf.

Wenn Sie anstelle eines Stashs ein reguläres Commit durchführen und dann eine erneute Basis erstellen, kopiert die Rebase das reguläre Commit. Wenn Sie es verwenden git reset --soft, um es zu verwerfen, geben Sie es auf die gleiche Weise auf, wie Sie das Versteck durch Poppen aufgegeben hätten. Letztendlich tun diese beiden also fast dasselbe (mit der Ausnahme, dass alle Änderungen, die Sie aufgrund des rebaseEreignisses während des rebaseSchritts vornehmen müssen , und nicht des git stash apply && git stash dropSchritts ).

Beachten Sie, dass das Anwenden des Stashs in zwei Schritten oder in drei Schritten erfolgt, wenn drei Commits vorhanden sind: Zuerst wendet Git die Indexänderungen an, dann die Änderungen am Arbeitsbaum (und bei Bedarf nicht verfolgte Dateien). Wenn Sie --indexbeim Anwenden das Flag verwenden, versucht Git, die Änderungen in "Bereitgestellt" und "Nicht Bereitgestellt" wiederherzustellen, genau so, wie Sie es getan haben, als Sie git stash saveden Stash-Bag erstellt haben. Ansonsten werden sie einfach zu einem Arbeitsbaum zusammengefügt.

(Dieses Zusammenspiel ist ein weiterer Grund, es git stash applyseparat zu verwenden , da Sie sie zurücksetzen können und git stash apply --indexwenn Sie dies beabsichtigt haben ... aber nur, wenn Sie den Vorrat noch nicht fallen gelassen haben.)

¹ Das Stash-Skript führt das dritte Commit durch, wenn Sie nicht bereitgestellte oder alle Dateien verwenden -uoder -averstauen. In diesem Fall wird stashimmer noch auf Commit verwiesen w, es wgibt jedoch ein drittes übergeordnetes Commit, das diese zusätzlichen Dateien enthält. Dieses dritte Commit hat kein eigenes übergeordnetes Element, im Gegensatz zum iCommit, das dasselbe übergeordnete Element hat wie w. Mit anderen Worten, der Stash Bag hängt immer noch vom gleichen Commit ab wie immer, aber jetzt hat er ein zusätzliches Root-Commit als drittes Elternteil, was überhaupt schwer zu beschreiben ist.

² Oder drei, wie in der vorherigen Fußnote.

^{3 Die} Verwendung von " git stash popEinfach" wird ausgeführt git stash apply && git stash drop, wenn auch etwas effizienter, da alles in einem Skript und nicht als zwei separate Befehle ausgeführt wird. Wenn die applyvollständig ausfällt, das dropgeschieht nicht, aber wenn die applyArbeiten und schief geht, das drop nicht passieren. Wenn Sie also feststellen, dass die Anwendung ein Durcheinander verursacht hat und Sie zurückgehen und sie in eine git stash savespätere konvertieren möchten , ist es zu spät.

Der git stash branchCode konvertiert den Stash in einen neuen Zweig. Wenn das Commit, an dem der Stash-Bag hängt, abgebrochen wurde, wird das Commit (und alle seine Eltern) unter dem neuen Filialnamen wiederbelebt.