Git verstecke zwei Branches

Lesezeit: 6 Minuten

Benutzeravatar von Gabriel Ferraz
Gabriel Ferraz

Dies ist die Situation:

  1. Ich habe Änderungen an Zweig A vorgenommen
  2. git stash auf Zweig A
  3. git checkout B
  4. Änderungen an Zweig B vorgenommen
  5. git stash auf Zweig B
  6. git checkout A
  7. git stash pop auf Zweig A

Nach Schritt 7 der obigen Liste kamen die Änderungen, die ich an Zweig A vor dem Stashing vorgenommen hatte, nicht zurück, aber die Änderungen, die ich an Zweig B vorgenommen hatte, tauchten in Zweig A auf. Ich habe verwendet cmd z auf Zweig A und die Datei kehrte in ihren vorherigen Zustand zurück, der die von mir vorgenommenen Änderungen enthielt. Es schien, dass der LEITER von Zweigstelle A zum LEITER von Zweigstelle B wechselte. Dasselbe geschah, als ich git checkout B und git stash pop auf diesem Zweig: Zweig B hatte alle Änderungen, die an Zweig A vorgenommen wurden, aber nicht die Änderungen, die ich an Zweig B vorgenommen hatte. Ich verwendete cmd z erneut, um zu dem Zweigstatus zurückzukehren, den ich brauchte.

Dies verursachte mir eine Zeit lang viele Probleme, bis ich wieder Code für das Projekt committen durfte (niemand konnte für eine Weile committen, weil es bei Commits einen automatischen Push zum Server gab und der Manager keinen neuen Code in der Server, bis sie einige Tests durchgeführt haben). Wie kann ich nur die Änderungen, die an den Zweigen selbst vorgenommen wurden, und keine Änderungen, die an anderen Zweigen vorgenommen wurden, öffnen?

  • Ich kenne kein Feature, das einen Stash an einen Zweig bindet. Ein Stash-Eintrag hat jedoch eine Beschreibung, und standardmäßig enthält diese Beschreibung den Namen des Zweigs, aus dem er erstellt wurde. Sie können verwenden git stash list um diese Beschreibungen zu sehen. Dann zB verwenden git stash pop stash@{1} um das zweite Element aus dem Stapel zu holen.

    – Raffael

    26. Juni 2016 um 0:47 Uhr


  • Außerdem scheint automatisiertes Push-after-Commit eine schreckliche Idee zu sein! Lokale Commits sind DIE wichtigste Verbesserung verteilter Versionskontrollsysteme gegenüber dem klassischen zentralisierten Ansatz. Das und Sicherung.

    – Raffael

    26. Juni 2016 um 0:50 Uhr

  • @Raffael: Ich werde diesen Befehl ausprobieren. Was den automatisierten Push betrifft, denke ich, dass er aus irgendeinem Grund vorübergehend war (im Allgemeinen stimme ich Ihnen jedoch zu). Ich bin vor etwa 2 Wochen zu dem Projekt gekommen und gewöhne mich immer noch daran, wie die Dinge laufen.

    – Gabriel Ferraz

    26. Juni 2016 um 1:21 Uhr


  • Automatisches Pushen auf einen Backup-Server wäre eine Funktion; womit du arbeitest ist schlichtweg dumm. +++ Ich habe gelernt, mich nicht zu überanstrengen git stash auf die harte Tour und ich würde Ihnen empfehlen, es nur für einfache Dinge zu verwenden. Wenn es komplizierter wird, greife ich zu temporären Filialen. Selbst mit richtig benannten Stash-Einträgen kann man sich zu leicht verirren. +++ Gibt’s auch git stash show -p stash@{1} um es mit Details und ähnlichen Dingen anzuzeigen, aber das Arbeiten mit Zweigen ist einfacher.

    – maaartinus

    26. Juni 2016 um 3:53 Uhr

  • Ich stimme zu, Verzweigung ist besser. Oder erstellen Sie ein temporäres Commit am Anfang des aktuellen Zweigs (ich nenne es gerne WIP – work in progress). Was auch immer besser zu Ihrem Szenario passt.

    – Raffael

    26. Juni 2016 um 8:49 Uhr

Toreks Benutzeravatar
Torek

Was git stash macht ein Commit.1

Natürlich was git commit macht ein Commit. Warum also haben wir git stash überhaupt?

Ein wesentlicher Unterschied zwischen diesen Befehlen besteht darin, dass die Commits git stash macht sind nicht auf irgendwelche Zweige. Dies ermöglicht Ihnen stash Wenn Sie sich auf einem Zweig befinden, wechseln Sie zu einem anderen Zweig und wenden Sie das Stash dort an. Mit anderen Worten, Sie können laufende Arbeit verschieben.

Häufig, aber nicht immer, können Sie laufende Arbeiten ohnehin verschieben. Siehe Git – Auschecken eines anderen Zweigs, wenn es nicht festgeschriebene Änderungen am aktuellen Zweig gibt. Wenn du kippenaber Sie können verwenden git stash damit umzugehen.

Wenn Sie andererseits, wie in Ihrem Fall, “in einem Zweig lagern” möchten, sind Sie wahrscheinlich besser dran, wenn Sie einfach einen regulären Commit durchführen, anstatt einen speziellen Stash-Commit durchzuführen. Solche Commits sind einfacher zu handhaben und haben auch keinen Bug git stash hat. Es ist unwahrscheinlich, dass Sie auf diesen Fehler stoßen, aber “normale Commits sind einfacher und einfacher zu handhaben” (Commits auf Branches vs. Stashes) ist ein ziemlich guter Grund, es zu vermeiden git stash.

Wenn Sie es vorziehen zu verwenden git stash Beachten Sie auf jeden Fall, dass jeder neue Stash die vorherigen in einem “Stash Stash” nach oben “schiebt”. Der alte Vorrat wird stash@{1}und was war stash@{1} wird stash@{2}, usw. Wenn du drop (verwerfen) bzw pop (versuchen anzuwenden, dann abwerfen) ein Versteck, die darüber gestapelten wandern wieder nach unten – also, wenn Sie es tun würden git stash drop stash@{3} als du hattest stash@{4} und stash@{5} außerdem würden Sie mit gelassen werden stash@{3} und stash@{4} jetzt.

Sie können jeden Stash, einschließlich des neuesten, folgendermaßen benennen: stash@{0} bedeutet dasselbe wie stash. (Git implementiert all dies tatsächlich mit der neu loggen Pro stash.)


1Tatsächlich macht es mindestens zwei Commits, und manchmal drei. Die beiden Commits speichern den Index und den Zustand des Arbeitsbaums; der dritte Commit, falls vorhanden, stammt von -u oder -a und speichert das unstaged (-u) oder alle (-a) Dateien. Der Work-Tree-Commit ist ein sehr seltsamer Merge-Commit, mit dem Index-Commit als zweitem Elternteil und dem dritten Commit, falls vorhanden, als drittem Elternteil. Der erste Elternteil des Arbeitsbaum-Commits und der einzige Elternteil des Index-Commits ist der Commit, der aktuell war, als Sie ausgeführt wurden git stash.

Wenn Sie Commit-Graph-Fragmente zeichnen – was immer dann eine gute Idee ist, wenn Sie irgendetwas Kompliziertes in Git machen –, hängt das Commit-Paar aus Index und Arbeitsbaum irgendwie vom ursprünglichen Commit ab, mit dem refs/stash Referenz, die auf das Paar zeigt, und nicht auf den Zweignamen. Es sieht fast aus wie eine kleine Handtasche oder ein Lebensmittelversteck, das an einem Ast hängt, um es von Bären fernzuhalten, oder so etwas, also bezeichne ich es gerne als “Stash Bag”.

Torek bietet (wie üblich) eine ausgezeichnete Antwort, aber ich glaube, die prägnante Antwort hier ist nur anzumerken, dass der Stash Daten als Stack (LIFO) enthält. Wenn Sie also die Arbeit von A und dann die Arbeit von B gepusht haben, erscheint zuerst B und dann A. Wenn Sie also zu A zurückgegangen sind und dann den ersten Pop gemacht haben, haben Sie die eingesparte Arbeit von B erhalten.

Wenn Sie einen Vorrat platzen lassen, wird der letzte Vorrat erneut angewendet, unabhängig davon, von welchem ​​​​Zweig Sie ihn gebunkert haben! Das Problem, das Sie posten, ist also, dass der letzte Stash, der auf Zweig B erstellt wurde, erneut auf Zweig A angewendet wurde. Beim nächsten Mal müssen Sie angeben, welchen Stash Sie öffnen möchten.

Lösung des gegebenen Problems:

  1. Stash nochmal den aktuellen Stand
  2. Pop das Stash, das vor dem letzten ist

Das ist alles.

wenn du tippst git stash list so etwas wird basierend auf Ihrer gegebenen Situation angezeigt

stash@{0}: WIP on branch-b
stash@{1}: WIP on branch-a

tippen git stash pop wird immer die bekommen stash@{0} Knoten.

Also, wenn du dabei bist branch a und Sie möchten Ihren Fortschritt in diesem Zweig anwenden. Basierend auf der Liste sollten Sie Folgendes eingeben:

git stash pop stash@{1}

1440510cookie-checkGit verstecke zwei Branches

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy