In Git, ist es möglich, einen Stash zu erstellen, den Stash zu einem Remote-Repository zu schieben, den Stash auf einem anderen Computer abzurufen und den Stash anzuwenden?Ist es möglich, einen Git Stash zu einem Remote-Repository zu pushen?
Oder sind meine Optionen:
Es ist nicht möglich, es per Abruf oder so zu bekommen, der Spiegel Refspec ist fetch = +refs/*:refs/*, und obwohl Stash ist refs/stash wird es nicht gesendet. Ein expliziter refs/stash:refs/stash hat auch keine Wirkung!
Es wäre sowieso nur verwirrend, denn das würde nicht alle Hüllen holen, nur die letzte; die Liste der Verstecke ist die Reflog der Ref refs/stashes.
Ich würde mit dem zweiten Ansatz gehen, obwohl keine Ahnung, warum Sie es nicht zu Master/Feature-Zweig verpflichten können. Es ist auch möglich, Rosinen zu pflücken.
Es gibt keinen technischen Grund, nicht zu Master zu begehen/kennzeichnete, nur, dass ich sagen will „Diese verpflichten keine wirkliche ist, ist es sparend nur meine Arbeit, so kann ich es auf einem anderen Rechner bekommen“. –
Ich bin ein wenig zu spät zur Party, aber ich glaube, dass ich etwas gefunden habe, das für mich in dieser Hinsicht funktioniert und es könnte auch für dich sein, wenn deine Umstände gleich oder ähnlich sind.
Ich arbeite an einer Funktion in einem eigenen Zweig. Der Zweig wird nicht mit dem Master verschmolzen und bis zum Ende geschoben, oder ich habe Commits gemacht, die ich der Öffentlichkeit zeigen möchte. Also, was ich tun, wenn ich nicht inszenierten Änderungen auf einen anderen Computer übertragen möchten, ist:
[non-commit] FOR TRANSFER ONLY“ vorstellen, die Inhalte, die Sie übertragen möchten.Dann tun:
git pull ssh+git://<username>@<domain>/path/to/project/ rb:lb
Die URL könnte für Sie unterscheiden sich, wenn Sie das Repository in einer anderen Art und Weise zuzugreifen. Dies zieht Änderungen von dieser URL von der entfernten Verzweigung "rb" in die lokale Verzweigung "lb". Beachten Sie, dass ich einen SSH-Server auf meinem eigenen Computer habe und auf diese Weise auf das Repository zugreifen kann.
git reset HEAD^ (impliziert --mixed)
Dies setzt den Kopf auf den Zustand vor dem Punkt "[Nicht-Commit]" begehen.
Von git-reset (1): "--mixed: Setzt den Index aber nicht die Arbeits Baum (dh die geänderten Dateien erhalten bleiben, aber nicht markiert für begehen) [...]"
So haben Sie Ihre Änderungen an den Dateien am Ende, aber keine Commits gemacht, um zu meistern und keine Notwendigkeit für ein Versteck.
Dies wird jedoch erfordern Sie git reset --hard HEAD^ in dem Repository, in dem Sie die "[non-commit]" gemacht, da dieses Commit Müll ist.
Hinweis: ich gerade diese Antwort mit 24 Stunden mehr git-fu unter meinem Gürtel neu geschrieben habe :) In meiner Shell-Geschichte ist der ganze Kram jetzt drei Einzeiler. Allerdings habe ich sie für Ihre Bequemlichkeit nicht aufgelöst.
Auf diese Weise hoffe ich, dass Sie sehen können, wie ich Dinge gemacht habe, anstatt nur blind Dinge kopieren/einfügen zu müssen.
Hier ist Schritt für Schritt.
Angenommen, es handelt sich um eine Quelle in ~/OLDREPO-haltigen Magazinen. Erstellen Sie einen Test Klon enthält keine stashes:
cd ~/OLDREPO
git clone . /tmp/TEST
Drücken alle stashes als Temp Zweige:
git send-pack /tmp/TEST $(for sha in $(git rev-list -g stash); \
do echo $sha:refs/heads/stash_$sha; done)
Schleife auf der Empfängerseite in stashes zu verwandeln zurück:
cd /tmp/TEST/
for a in $(git rev-list --no-walk --glob='refs/heads/stash_*');
do
git checkout $a &&
git reset HEAD^ &&
git stash save "$(git log --format='%s' -1 [email protected]{1})"
done
Cleanup Ihre temporäre Zweige, wenn Sie werden
git branch -D $(git branch|cut -c3-|grep ^stash_)
eine git stash Liste tun und Sie werden so etwas wie diese:
[email protected]{0}: On (no branch): On testing: openmp import
[email protected]{1}: On (no branch): On testing: zfsrc
[email protected]{2}: On (no branch): WIP on sehe: 7006283 fixed wrong path to binary in debianized init script (reported as part of issue
[email protected]{3}: On (no branch): WIP on debian-collab: c5c8037 zfs_pool_alert should be installed by default
[email protected]{4}: On (no branch): WIP on xattrs: 3972694 removed braindead leftover -O0 flag
[email protected]{5}: On (no branch): WIP on testing: 3972694 removed braindead leftover -O0 flag
[email protected]{6}: On (no branch): WIP on testing: db9f77e fuse_unmount_all could be starved for the mtx lock
[email protected]{7}: On (no branch): WIP on xattrs: db9f77e fuse_unmount_all could be starved for the mtx lock
[email protected]{8}: On (no branch): WIP on testing: 28716d4 fixed implicit declaration of stat64
[email protected]{9}: On (no branch): WIP on emmanuel: bee6660 avoid unrelated changes
Auf der Original-Repository, das gleiche sah aus wie
[email protected]{0}: WIP on emmanuel: bee6660 avoid unrelated changes
[email protected]{1}: WIP on testing: 28716d4 fixed implicit declaration of stat64
[email protected]{2}: WIP on xattrs: db9f77e fuse_unmount_all could be starved for the mtx lock
[email protected]{3}: WIP on testing: db9f77e fuse_unmount_all could be starved for the mtx lock
[email protected]{4}: WIP on testing: 3972694 removed braindead leftover -O0 flag
[email protected]{5}: WIP on xattrs: 3972694 removed braindead leftover -O0 flag
[email protected]{6}: WIP on debian-collab: c5c8037 zfs_pool_alert should be installed by default
[email protected]{7}: WIP on sehe: 7006283 fixed wrong path to binary in debianized init script (reported as part of issue #57)
[email protected]{8}: On testing: zfsrc
[email protected]{9}: On testing: openmp import
Ich lerne ein viel in kurzer Zeit, und ich glaube, ich sollte wahrscheinlich einfach viele Gebräuche in meinem früheren Ansatz gebrauchen, was ich später versuchen werde. – sehe
Dies funktionierte gut für mich, außer dass ich ein 'git add.' Vor dem 'git stash save ...' schritt brauchte, da 'git stash' es ablehnt, neue Dateien zu speichern, wenn sie nicht inszeniert wurden. Wenn Sie das Ergebnis von 'git rev-list ...' durch 'tac' weiterleiten, kehrt sich die Reihenfolge der Blöcke um, sodass sie in derselben Reihenfolge ausgegeben werden. –
@AlanKrueger Ich habe diese Antwort nicht versucht, aber 'git stash save -u' kann helfen. – hiroshi
AFAIK die ganze Idee von Stash ist etwas nicht so zu verbergen -wichtig unter dem lokalen Teppich. Niemand sollte über deinen Lieblingsmist Bescheid wissen ;-) Das einzige "Aber" ist: Aber wenn ich mich auf ein paar Workstations entwickle? Dann ist scp viel besser.
Etwas dieses lustige sollte ein Kommentar sein. ;-) –
Total git-ssh-newbie hier aber kannst du scp mit github dann benutzen? – Koen
Nein, gith-ssh-Frontend von github ist so programmiert, dass Sie nie eine SSH-Shell/Konsole haben. Es kann nur den serverseitigen Git-Prozess ausführen. –
Es ist ein bisschen spät, aber diese Antwort könnte jemandem helfen. Ich wollte das wissen, weil ich in der Lage sein wollte, eine laufende Funktion/einen Fehler/was auch immer zu machen und von demselben Punkt aus auf einem anderen Computer zu arbeiten.
Was für mich funktioniert ist, meinen laufenden Code (in einem Zweig, an dem ich gerade arbeite) zu begehen. Als ich zu meinem anderen Computer zu bekommen, macht einen Zug, dann rückgängig gemacht werden mit dem Commit:
git reset --soft HEAD^
weiter arbeiten, wie Sie waren, mit all in-progress Änderungen gibt, nicht gebundene und unstaged.
Ich hoffe, es hilft.
Wenn ich dies versuche, behält der Origin immer noch den Commit, der nicht festgeschrieben wurde. Nah aber keine Zigarre für mich. – rezwits
@rezwits Ja, die Fernbedienung behält es, aber es ist einfach genug, einfach den temporären Zweig vom Ursprung zu löschen. –
Genau das habe ich gemacht! – rezwits
Folgendes funktioniert nicht mit dem Stash, aber mit den nicht festgeschriebenen Änderungen im Arbeitsverzeichnis. Es schafft einen Zweig, autocommits alle aktuellen Änderungen und drückt auf die Fernbedienung:
commit_and_push_ () {
# This will:
# 1. checkout a new branch stash-XXX
# 2. commit the current changes in that branch
# 3. push the branch to the remote
local locbr=${1:-autostash-XXX}
git checkout -b $locbr
git add .
git commit -a -m "Automatically created commit"
git push origin $locbr
echo "Autocommitted changes in branch $locbr ..."
}
Verwendung wie:
commit_and_push_ my-temp-branch
commit_and_push_
Es scheint ein sehr netter Trick, um dies zu lösen. Sie können git diff > file.diff verwenden (und die Datei festschreiben) und dann die Änderungen mit git apply file.diff (von überall) wiederherstellen, um das gleiche Ergebnis zu erzielen.
Dies wurde auch here erklärt.
Wenn Sie nicht geordnete Dateien haben: 1. git add. 2. git diff HEAD> file.diff – trickpatty
Verwenden Sie einfach Dropbox wie dieser Typ. Auf diese Weise müssen Sie sich keine Sorgen machen, Push-Speicher zu verschieben, da Ihr gesamter Code gesichert wird.
Bevor irgendjemand eine reflexartige Reaktion hat, sage ich nicht, Dropbox anstelle von Github zu verwenden, sondern Code zu speichern, der nicht für einen Commit in Dropbox bereit ist, der immer noch unter der Version wäre lokal steuern. –
Es dauert zu viel Zeit, um das gesamte Projekt in die entfernte Cloud zu kopieren. –
Sie können den neuesten Stash von einer Git-Fernbedienung holen, aber nicht in Ihr Versteck, nur in eine andere Referenz. So etwas wie 'git fetch some-remote + refs/stash: refs/remotes/some-remote/stash' das' git stash apply some-remote/stash'. Sie können jedoch keine älteren Speicherbereiche abrufen, da sie im Reflog gespeichert sind, der nicht abgerufen werden kann. Siehe http://stackoverflow.com/questions/2248680/can-i-fetch-a-stash-from-a-remote-repo-into-a-local-branch/29839687#answer-29839687 – sj26