Sollte ich git stash verwenden, um laufende Änderungen meines Projekts zu speichern und es an github zu senden, um auf andere Computer zuzugreifen?


20

Ich arbeite sehr oft an einigen Funktionen meines Projekts, die ich unterbrechen muss, bevor sie für ein Commit ausreichen. Ich benutze jedoch täglich zwei verschiedene Computer zum Codieren (meinen Laptop und meinen Forschungslabor-Desktop). ZB: Ich arbeite zu Hause an einem Feature, dann höre ich auf und gehe in mein Labor.

Ich möchte keine Cloud-Synchronisierung (z. B. Dropbox) mit GitHub-Remote-Tracking mischen.

Ich habe einfach unfertige (und unordentliche) Zustände meines Codes vorher festgeschrieben (und es gepusht), nur um das in den anderen Computer zu ziehen, um die Arbeit fortzusetzen. Ich bin mir ziemlich sicher, dass dies eine schlechte Praxis ist.

Heute bin ich allerdings git stashnach dem Googeln ein bisschen rübergekommen. Es scheint die perfekte Lösung für das zu sein, was ich brauche.

In der Dokumentation wird jedoch nicht angegeben, ob es nach dem Pushen der Änderungen an Github geht. Außerdem möchte ich wissen, ob es einen effizienteren Weg gibt, um die von mir benötigte Mobilität zu erreichen.

Danke im Voraus!


1
Ich stimme dafür, diese Frage als "Off-Topic" zu schließen, da sie bereits auf Stack Overflow
David Arno,

5
@DavidArno: Ich glaube nicht, dass es sich um ein Cross-Site-Duplikat handelt. In der StackOverflow-Frage geht es um "Kann ich X machen" und in dieser Frage geht es um "Ist X eine gute Übung?". Im allerwenigsten ist die eigentliche Ursache der Frage anders.
Greg Burghardt

7
@DavidArno das letzte Mal, dass ich überprüft habe, "Bereits auf SO beantwortet" ist kein Grund, eine Frage zu schließen.
RubberDuck

Antworten:


28

Ich habe einfach unfertige (und unordentliche) Zustände meines Codes vorher festgeschrieben (und es gepusht), nur um das in den anderen Computer zu ziehen, um die Arbeit fortzusetzen. Ich bin mir ziemlich sicher, dass dies eine schlechte Praxis ist.

Es ist in Ordnung, schmutzige, unfertige Arbeiten zu verrichten. Arbeiten Sie in einer Themenbranche. Legen Sie früh fest und legen Sie häufig fest. Lesen Sie weiter Wann soll Code festgeschrieben werden? Für einige Richtlinien, wann ein Commit durchgeführt werden soll. Speziell für Git können Sie sich einem Zweig widmen und ihn so oft verschieben, wie Sie möchten.

Wenn dieser Zweig nur für Sie bestimmt ist, schreiben Sie defekten Code fest und übertragen Sie ihn. Sie sollten es nur unterlassen , fehlerhaften Code an einen Zweig weiterzuleiten , der von anderen Personen verwendet wird. Zögern Sie nicht, Ihren eigenen Code zu knacken.


6
Ich würde es sogar stärker sagen: Arbeite niemals am Hauptzweig, sondern benutze immer einen Zweig mit Themen. Setzen Sie sich dafür ein, wie Sie es für richtig halten, und treiben Sie es ohne Furcht voran. Wenn Sie mit den Änderungen zufrieden sind, führen Sie sie zum Master zusammen.
9000

Guter Rat! Ich denke, die große Verwirrung könnte passieren, weil wir einem Commit einen Kommentar hinzufügen müssen, und manchmal wird es buchstäblich so etwas wie "Aufgabe in Bearbeitung" oder so ähnlich sein. Und ja, ich arbeite alleine in dieser Branche, also macht alles, was Sie gesagt haben, Sinn!
Leandro

4
Dies gibt Ihnen auch die Möglichkeit, einzelne Commits zu einem zusammenzufassen, wenn Sie Ihren Branch Git Merge - Squash Bugfix
Snoopy

2
@Leandro-Commit-Nachrichten sollten so atomar und klar sein, wie es Sinn macht. Selbst wenn es sich um WIP handelt, können Sie beispielsweise "Hinzufügen eines Controllers zur Verarbeitung von Seitenanforderungen - WIP" sagen. Commit-Nachrichten bieten auch einen durchsuchbaren Verlauf der am Projekt vorgenommenen Änderungen. Zehn Commits von "WIP" würden niemandem helfen, nach einer Änderung zum Beispiel im Umgang mit Benutzern zu suchen.
Ben

7

Verstecke sind für den lokalen Gebrauch gedacht, als vorübergehender Ort, um Dinge zu verstauen, während Sie mit Zweigen herumspielen.

Wenn Sie der einzige sind, der an einem Zweig arbeitet, gibt es kein Problem damit, fehlerhaften Code zu schreiben. Was ich in ähnlichen Situationen tue, ist, ein unterbrochenes Commit auszuführen und es nach dem Ziehen an der anderen Stelle wieder git reset HEAD~1rückgängig zu machen. Dies setzt natürlich voraus, dass Sie --forceauf Ihrem pullsund pusheswenn Sie den Standort wechseln.

Oder ich warte einfach bis zu meinem ersten Commit und mache einen git commit --amend. Oder ich drücke einfach alle unterbrochenen Commits aus, wenn ich den Feature-Zweig festschreibe. Oder ich mache mir einfach keine Sorgen um ein paar klar gekennzeichnete, gebrochene Commits in meiner Geschichte, weil ich dazu neige, nicht zu gehen, bis ich an einem guten Halteplatz bin. Es gibt viele Möglichkeiten.


1
Ich würde nicht empfehlen, sich daran zu gewöhnen, --amendso dass es --forcefür die Schübe erforderlich ist. Besser nur auf einen Wegwerfzweig festlegen.
Leftaroundabout

1

stashist nicht wirklich zufriedenstellend, außer das Arbeitsverzeichnis zu bereinigen, um "Ihre Filiale zu entstören"; Wenn Sie stash popden Zustand nicht sofort wieder herstellen, wird es sehr verwirrend.

Wenn tatsächlich zu speichernde Arbeit vorhanden ist, sollte es sich dennoch um ein Commit handeln, auch wenn dies nicht für einen dauerhaften Repo-Eintrag geeignet ist. Tatsächlich lasse ich mein Arbeitsverzeichnis nie in einem Zustand, der nicht unter Versionskontrolle steht. Ich verwende einige sehr einfache Python-Skripte , um jede Änderung als temporäres Commit zu speichern. Wenn Sie das ausprobieren möchten, gehen Sie wie folgt vor:

  1. Wenn Sie eine noch nicht abgeschlossene Arbeit erledigt haben und den Arbeitsplatz verlassen möchten, führen Sie diese aus git-tmp-commit. Alle Änderungen werden automatisch in einen neuen, eindeutigen Zweig übernommen.
  2. Schieben Sie diesen Zweig zur Fernbedienung.
  3. Verlassen.
  4. Wenn Sie fortfahren möchten, klonen Sie diesen Zweig erneut von der Fernbedienung. Ich mache das mit dem ccdSkript, das tatsächlich alles von Grund auf in einen temporären Ordner auscheckt und automatisch den neuesten Zweig auswählt. Sie können den Zweig aber auch einfach manuell temporary-commits/original-branch/YYYY-MM-DD...von einem vorhandenen Klon des Repos abrufen und auschecken.
  5. Zuletzt die Änderungen mit "aufheben" git-tmp-commit -r. Auf diese Weise kehren Sie zum ursprünglichen Zweig † zurück (z. B. master) und belassen die Änderungen des temporären Commits im Arbeitsverzeichnis. Sie können also hier fortfahren, bis es Zeit für ein ordnungsgemäßes Commit ist (oder temporär, wenn Sie es erneut verlassen müssen).

So wie das Skript jetzt geschrieben ist, funktioniert dies nur, wenn im Checkout-Repo keine Verzweigung vorhanden istmaster . Im Zweifelsfall müssten Sie also git branch -d master; das ist offensichtlich nicht wirklich ideal ...

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.