Bewahren Sie die Arbeit auf und setzen Sie sie sicher fort

• Wählen Sie aus, was in einem Stash gespeichert werden soll: nachverfolgte Bearbeitungen, nicht nachverfolgte Dateien oder nur das, was bereitgestellt wird.
• Erklären Sie, warum Apply den Vorrat behält und Pop ihn erst nach einer sauberen Anwendung entfernt.
• Stellen Sie sicher, dass sowohl die Bearbeitung als auch die Notiz zurückkamen und der Zweig nicht verschoben wurde.
• Erholen Sie sich von einem Pop-Konflikt, ohne den Vorrat zu verlieren.

Sie befinden sich auf private/stash-hint, einem Zweig aus dem Ergebnis von Lektion 18, mit einem Commit, der docs/stash-conflict.md hinzufügt („Verwenden Sie eine fiktive Adresse.“). In Ihrem Arbeitsbaum haben Sie eine noch nicht abgeschlossene Bearbeitung dieser Datei und eine neue Datei, docs/signup-hint.md, die Git noch nie gesehen hat. Jemand bittet Sie, zu etwas anderem zu wechseln, also möchten Sie, dass beides beiseite gelegt wird, ohne halbfertige Arbeit zu leisten.

Alles ist lokal und im kostenlosen Plan (GitTree fordert Sie auf, sich anzumelden): kein Hosting-Konto, kein Anbieter, kein Internet. Jede Identität ist fiktiv (example.com). Führen Sie diese Lektion niemals in einem echten Projekt aus.

Nehmen Sie die Änderungen in GitTree oder mit den nativen Git-Befehlen vor, nicht beides in derselben Kopie. Das Ablesen des Ergebnisses ist immer sicher. Die Menübezeichnungen stammen aus den eigenen Strings von GitTree 2.0 und die nativen Befehle wurden mit Git 2.43 in Einwegkopien ausgeführt. Die GitTree-Schritte wurden nicht auf macOS, Windows oder Linux ausgeführt.

Stash speichert Ihre lokalen Änderungen als Git-Objekte und bereinigt dann den Arbeitsbaum bis zum letzten Commit. Es handelt sich um ein Tool zur kurzen Unterbrechung, nicht um ein Backup und auch nicht um einen Ersatz für einen Zweig, den Sie behalten möchten.

Ein Stash enthält standardmäßig nachverfolgte Änderungen. Nicht verfolgte Dateien bleiben zurück, es sei denn, Sie fragen danach, was Git mit --include-untracked tut. GitTrees Stash Changes…-Dialogfeld hat Include untracked files eingeschaltet, wenn es geöffnet wird; überprüfe es trotzdem. Ignorierte Dateien gehören zu einer anderen Kategorie und werden hier nicht gespeichert. Only staged changes speichert genau das, was im Index enthalten ist, und Keep staged changes in place too lässt den Index unverändert.

Apply Stash setzt die Änderungen zurück und behält den Stash in der Liste. Pop Stash wendet es an und entfernt den Eintrag nur, wenn die Anwendung sauber war. Wenn ein Konflikt auftritt, bleibt der Stash erhalten und Sie lösen den Konflikt im Arbeitsbaum. GitTrees Apply und Pop stellen den bereitgestellten Zustand nicht wieder her; git stash apply --index macht das, aber die App verwendet es nicht, sodass bereitgestellte Änderungen nicht bereitgestellt zurückkommen.

Beim Stashing und Anwenden wird der Zweig niemals verschoben oder ein Commit durchgeführt. Lediglich der Arbeitsbaum und ein Stash-Eintrag ändern sich.

Beginnen Sie mit einer separaten, normalen Kopie des Projekts, so wie es in Lektion 18 belassen wurde, und lassen Sie Ihr Original gittree-features unberührt. Erstellen Sie den Zweig, speichern Sie DOC_STASH_BASE und schreiben Sie ihn fest. Speichern Sie dann DOC_STASH_WORK über derselben Datei und DOC_HINT als neue Datei, auch ohne Staging. DOC_STASH_OTHER und STASH_RESOLVED werden nur in der separaten Konfliktkopie verwendet.

Speichern Sie nur in der unten genannten Phase. Dabei handelt es sich um vollständige UTF-8/LF-Körper mit einem abschließenden Zeilenumbruch; Fügen Sie niemals Markdown-Zäune ein. Unveränderte ausführbare Dateien erben die benannte Eingabe. Versionen in separaten Varianten dürfen das Original nicht überschreiben.

docs/stash-conflict.md – DOC_STASH_BASE

Use a fictional address.

docs/stash-conflict.md – DOC_STASH_WORK

Use a complete fictional email address.

docs/signup-hint.md – DOC_HINT

Unfinished signup hint: use fictional data only.

docs/stash-conflict.md – DOC_STASH_OTHER

Do not send the address anywhere.

docs/stash-conflict.md – STASH_RESOLVED

Use a complete fictional email address. Nothing is sent.

Öffnen Sie die Palette mit Befehl+Umschalt+P (Strg+Umschalt+P bei Ubuntu). Stash-Einträge werden im linken Bereich unter Stashes aufgelistet; Die Aktionen eines Verstecks ​​befinden sich im Kontextmenü.

1. Erstellen Sie den Zweig und die beiden nicht bereitgestellten Änderungen, wie im nächsten Abschnitt gezeigt. Lesen Sie die Änderungsliste: docs/stash-conflict.md wurde geändert und docs/signup-hint.md ist neu.
2. Öffnen Sie die Palette und führen Sie Stash Changes… aus. Stellen Sie im Dialogfeld Message auf signup hint rehearsal ein. Only staged changes ist ausgeschaltet. Include untracked files ist eingeschaltet. Keep staged changes in place too ist ausgeschaltet. Wählen Sie Stash.
3. Warten Sie auf die Meldung „Änderungen gespeichert“. Die Änderungsliste ist leer, die Notiz ist vom Datenträger verschwunden und der Stash erscheint unter Stashes.
4. Bewegen Sie den Mauszeiger über die Stash-Zeile: Der Tooltip lautet „Enthält nicht verfolgte Dateien“. Klicken Sie mit der rechten Maustaste darauf und wählen Sie Show Stash: Das Diagramm wählt den Stash aus und im rechten Bereich wird die nachverfolgte Änderung docs/stash-conflict.md aufgeführt. Die nicht verfolgte Notiz wird in einem separaten Teil des Vorrats aufbewahrt.
5. Klicken Sie erneut mit der rechten Maustaste darauf und wählen Sie Apply Stash. In der Mitteilung steht: „Der Vorrat wurde angewendet; er befindet sich immer noch in der Liste.“
6. Überprüfen Sie das Ergebnis: docs/stash-conflict.md wurde erneut geändert, docs/signup-hint.md ist als nicht verfolgte Datei zurück, der Branch-Tip ist derselbe Commit und der Stash wird weiterhin aufgelistet.
7. Separate conflict copy. Übertragen Sie DOC_STASH_OTHER in einer zweiten Kopie nach dem Stash in dieselbe Datei. Klicken Sie mit der rechten Maustaste auf den Stash und wählen Sie Pop Stash. Die Warnung lautet: „Der Stash steht im Konflikt mit Ihren Änderungen: Lösen Sie die Konflikte. Der Stash bleibt erhalten.“
8. Die Konfliktdatei wird mit Conflicted aufgeführt. Öffnen Sie es, schreiben Sie STASH_RESOLVED in die Ausgabe und wählen Sie Save and Mark Resolved. Der Vorrat ist noch da. Wenn Sie sicher sind, dass die Arbeit sicher ist, klicken Sie mit der rechten Maustaste darauf und wählen Sie Delete Stash…; Im Dialogfeld wird angezeigt, dass es aus der Liste entfernt und in den Wiederherstellungs-Snapshots beibehalten wird. Durch das Rückgängigmachen von GitTree wird ein gelöschter Stash noch nicht wiederhergestellt (Lektion 30). Behandeln Sie das Löschen daher als endgültig.

Für jeden gewöhnlichen Commit im Kurs: Summary ist das angegebene Subjekt, Description ist leer und die Optionen Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit und Allow Empty Commit bleiben ausgeschaltet.

In einer separaten Kopie des Ergebnisses von Lektion 18:

git switch --create private/stash-hint

Speichern Sie DOC_STASH_BASE als docs/stash-conflict.md, dann:

git add -- docs/stash-conflict.md
git commit --quiet -m "docs: establish the stash conflict baseline"

Speichern Sie DOC_STASH_WORK über docs/stash-conflict.md und DOC_HINT als docs/signup-hint.md, ohne Staging. Dann verstauen Sie beides:

git stash push --include-untracked --message "signup hint rehearsal"
git status --short
git stash list --format=%s

On private/stash-hint: signup hint rehearsal

Der Status gibt nichts aus: Der Baum ist sauber. Behalten Sie eine unberührte Kopie dieses Zustands für den Konflikt und wenden Sie dann Folgendes an:

git stash apply 'stash@{0}'
git status --short
git stash list --format=%s
git rev-parse HEAD

 M docs/stash-conflict.md
?? docs/signup-hint.md
On private/stash-hint: signup hint rehearsal

Beide Körper sind zurück, der Stash ist immer noch aufgelistet und HEAD ist der Commit, der er war. Ohne --include-untracked belässt derselbe Push docs/signup-hint.md auf der Festplatte und speichert nur die Bearbeitung.

Speichern Sie in der separaten Kopie DOC_STASH_OTHER, schreiben Sie es fest und öffnen Sie dann Folgendes:

git add -- docs/stash-conflict.md
git commit --quiet -m "docs: change the stash target"
git stash pop 'stash@{0}'
git ls-files --unmerged
git stash list --format=%s

Pop wird mit 1 beendet und gibt „CONFLICT (content)“ und „Der Stash-Eintrag wird aufbewahrt für den Fall, dass Sie ihn erneut benötigen“ aus. Drei nicht zusammengeführte Einträge werden aufgelistet, die Datei enthält Konfliktmarkierungen, docs/signup-hint.md wird wiederhergestellt und der Stash wird weiterhin aufgelistet. Es gibt keine Zusammenführung oder Rebase, um fortzufahren: Speichern Sie STASH_RESOLVED und führen Sie git add -- docs/stash-conflict.md aus. Um die Arbeit stattdessen in einem eigenen Zweig zu parken, erstellt git stash branch rescue-hint 'stash@{0}' den Zweig bei dem Commit, bei dem der Stash erstellt wurde, wendet ihn an und entfernt den Stash erst dann.

Where you end: in der ersten Kopie enthält der Baum erneut die Bearbeitung und die Notiz, HEAD wurde nicht verschoben und der Stash wird weiterhin aufgelistet. In der Konfliktkopie hat Pop den Konflikt gemeldet, der Vorrat hat überlebt und Ihre Lösung ist inszeniert. Kein Stash-Befehl hat einen Commit durchgeführt und nichts wurde gepusht.

• Vergessen Sie, dass nicht verfolgte Dateien nicht gespeichert werden, es sei denn, Sie schließen sie ein.
• Angenommen, Pop hat den Vorrat nach einem Konflikt gelöscht. Das war nicht der Fall.
• Zweimal anwenden, obwohl die erste Anwendung bereits funktioniert hat, und mich dann über doppelte Änderungen wundern.
• Verwendung eines Vorrats als Langzeitspeicher. Nennen Sie nützliche Arbeiten mit einer Branche.

Lassen Sie nach einem Pop-Konflikt den Stash an Ort und Stelle, lösen Sie die Datei auf und überprüfen Sie das Ergebnis, bevor Sie etwas löschen. Wenn Sie sich auf den falschen Zweig beworben haben, verwerfen Sie die Arbeit erst, nachdem Sie sich vergewissert haben, dass sie im Vorrat noch enthalten ist. Create Branch from Stash… gibt dem Stash bei dem Commit, bei dem es erstellt wurde, einen eigenen Zweig.

Beantworten Sie jede Frage und lesen Sie dann, warum. Mit „erforderlich“ gekennzeichnete Fragen zählen zum Abschluss der Lektion.

1. Frage 1 von 6

   Frage 1 von 6

   Was macht Pop Stash, was Apply Stash nicht kann?

   Wählen Sie eine Antwort.

   Der Stash-Eintrag wird entfernt, jedoch nur, wenn die Anwendung sauber war.

   Es stellt auch den bereitgestellten Zustand wieder her.

   Es übernimmt die gespeicherten Änderungen.

   Es verschiebt den Zweig zu dem Commit, in dem der Stash erstellt wurde.

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Sie führen „Stash Changes…“ mit der Option „Nicht verfolgte Dateien einschließen“ aus. Welche davon sind wahr?

   Wählen Sie jede zutreffende Antwort aus.

   Auch ignorierte Dateien werden zwischengespeichert.

   Die neue, noch nie gesehene Notiz kommt ebenfalls in den Vorrat.

   Der Arbeitsbaum geht zurück zum letzten Commit.

   Die Bearbeitung der verfolgten Datei wird im Stash gespeichert.

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   Nach dem Stash wählen Sie „Stash anwenden“. Was siehst du?

   Wählen Sie eine Antwort.

   Nur die Bearbeitung ist zurück; Die Notiz bleibt im Vorrat.

   Ein neuer Commit enthält die wiederhergestellten Änderungen.

   Die Bearbeitung ist zurück und der Vorrat ist weg.

   Die Bearbeitung und die Notiz sind zurück, die Zweigspitze bleibt unverändert und der Stash wird weiterhin aufgelistet.

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6

   Ändern Sie die Eingabe: Schalten Sie in einer Kopie die Option „Nicht verfolgte Dateien einbeziehen“ aus, bevor Sie sie speichern. Was passiert mit docs/signup-hint.md?

   Wählen Sie eine Antwort.

   Sie verbleibt als nicht verfolgte Datei auf der Festplatte und der Stash enthält nur die Bearbeitung.

   Es ist sowieso verstaut.

   Git löscht es.

   Der Vorrat wird abgelehnt.

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6Erforderlich

   In der Konfliktkopie warnt Pop Stash: „Der Stash steht im Konflikt mit Ihren Änderungen: Lösen Sie die Konflikte. Der Stash wird behalten.“ Sie machen sich Sorgen, dass die Arbeit weg ist. Was ist wahr und was tun Sie?

   Wählen Sie eine Antwort.

   Verwenden Sie einen Hard-Reset, um von vorne zu beginnen.

   Der Vorrat ist immer noch aufgeführt. Lösen Sie die Datei auf und markieren Sie sie als aufgelöst, überprüfen Sie das Ergebnis und löschen Sie den Stash nur, wenn Sie sicher sind.

   Führen Sie Pop sofort noch einmal aus.

   Löschen Sie jetzt den Vorrat, um ihn zu bereinigen.

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Welche Readbacks zeigen nach Apply Stash in der ersten Kopie, dass es wie in der Lektion beschrieben funktioniert hat?

   Wählen Sie jede zutreffende Antwort aus.

   git stash list --format=%s gibt immer noch „On private/stash-hint: signup hint rehearsal“ aus.

   git rev-parse HEAD entspricht der ID, die Sie vor dem Stashen notiert haben.

   git status --short zeigt die Bearbeitung an docs/stash-conflict.md und docs/signup-hint.md als nicht verfolgt an.

   git ls-files --unmerged listet drei Einträge auf.

   Antwort prüfen

Stellen Sie sicher, dass der Baum nach dem Stash sauber war, dass Apply beide Dateien wiederhergestellt hat und dass der Stash immer noch aufgeführt ist. Sagen Sie voraus, was anders wäre, wenn Include untracked files ausgeschaltet wäre. Beweisen Sie in der Konfliktkopie, dass der Vorrat den Pop überlebt hat.

• Wählen Sie die Stash-Optionen absichtlich aus.
• Übernehmen behält den Eintrag bei.
• Ein widersprüchlicher Pop behält es auch.

• Stellen Sie den beabsichtigten Snapshot bereit und führen Sie Ihren ersten Commit durch (Lektion 5)
• Merge- und Rebase-Konflikte lösen (Lektion 23)
• Laden Sie GitTree herunter

Stash – مخبأ; anwenden – تطبيق; Pop – تطبيق وحذف; untracked – غير متتبَّع.