En git, est-il possible de créer une cachette, de pousser la cachette vers un dépôt distant, de récupérer la cachette sur un autre ordinateur et d'appliquer la cachette?Est-il possible de pousser une mémoire git vers un dépôt distant?
Ou sont mes options:
Il n'est pas possible d'obtenir par l'intermédiaire de fetch ou alors, le miroir refspec est fetch = +refs/*:refs/*, et même si stash est refs/stash il n'est pas envoyé. Un refs/stash:refs/stash explicite n'a aucun effet non plus!
Cela ne serait que source de confusion car cela ne permettrait pas de récupérer toutes les caches, seulement la dernière; la liste des cachettes est la reflog de la réf refs/stashes.
je partirais avec la deuxième approche, bien que ne sais pas pourquoi vous ne pouvez pas engager à maîtriser/branche sélectionnée. Il est également possible de faire des cerises.
Il n'y a aucune raison technique de ne pas engager à maître/vedette, juste que je veux dire « Ce n'est pas un vrai commit, il est tout simplement sauver mon travail, je peux le faire sur une autre machine ». –
Je suis un peu en retard à la fête, mais je crois que j'ai trouvé quelque chose qui fonctionne pour moi à ce sujet et il pourrait pour vous aussi si votre situation est la même ou similaire. Je travaille sur une fonctionnalité dans sa propre branche. La branche n'est pas fusionnée en master et poussée jusqu'à ce qu'elle soit terminée ou j'ai fait des commits que je me sens à l'aise de montrer au public. Alors ce que je fais quand je veux transférer des changements non mis en scène à un autre ordinateur est:
[non-commit] FOR TRANSFER ONLY », avec le contenu que vous voulez transféré.Effectuez ensuite:
git pull ssh+git://<username>@<domain>/path/to/project/ rb:lb
L'URL peut être différente pour vous si vous accédez à votre référentiel d'une manière différente. Cela va tirer les changements de cette URL de la branche distante "rb" dans la branche locale "lb". Notez que j'ai un serveur ssh fonctionnant sur mon propre ordinateur et que je peux accéder au référentiel de cette façon.
git reset HEAD^ (implique --mixed)
Ce remet à zéro la tête pointer vers l'état avant la "[non-COMMIT]" engager.
De réinitialisation git (1): "--mixed: Remet l'index, mais pas l'arbre de travail (à savoir les fichiers modifiés sont conservés, mais pas marqué pour commettre) [...]"
Donc, vous aurez vos changements dans les fichiers à la fin, mais aucun commits sont faits au maître et pas besoin d'une cachette.
Cela nécessitera cependant que vous utilisiez git reset --hard HEAD^ dans le référentiel dans lequel vous avez effectué le "[non-commit]", car ce commit est garbage.
Note: Je viens réécrite cette réponse avec 24 heures plus git-fu sous ma ceinture :) Dans mon histoire shell, tout le tralala est maintenant trois one-liners. Cependant, je les ai décondensés pour votre commodité. De cette façon, j'espère que vous serez capable de voir comment j'ai fait les choses, au lieu de simplement copier/coller aveuglément des choses.
Voici étape par étape.
Supposons que la source soit dans ~/OLDREPO contenant des stashes. Créer un clone TEST ne contenant pas stashes:
cd ~/OLDREPO
git clone . /tmp/TEST
pousser tous les stashes que des branches temporaires:
git send-pack /tmp/TEST $(for sha in $(git rev-list -g stash); \
do echo $sha:refs/heads/stash_$sha; done)
boucle sur l'extrémité de réception pour transformer de nouveau en stashes:
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
Nettoyage de votre branches temporaires si vous voulez
git branch -D $(git branch|cut -c3-|grep ^stash_)
Faites une liste de git stash et vous quelque chose comme ceci:
[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
Sur le référentiel d'origine, le même ressemblait
[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
J'apprends un beaucoup dans peu de temps, et je pense que je devrais probablement simplement beaucoup d'utilisations de commande dans mon approche antérieure, que j'essaierai de faire plus tard. – sehe
Cela a bien fonctionné pour moi, sauf que j'avais besoin d'un 'git add. 'Avant l'étape' git stash save ... 'car' git stash' refuse de stocker de nouveaux fichiers, sauf s'ils ont été mis en scène. De plus, si vous passez le résultat de 'git rev-list ...' à 'tac', vous inversez l'ordre des stash pour qu'ils sortent dans le même ordre. –
@AlanKrueger Je n'ai pas essayé cette réponse, mais 'git stash save -u' peut aider. – hiroshi
AFAIK l'idée de Stash est de cacher quelque chose pas si -important sous le tapis local. Personne ne devrait savoir sur votre merde préférée ;-) Le seul "mais" est: Mais si je développe sur quelques postes de travail? Alors scp est bien meilleur.
Quelque chose de drôle devrait être un commentaire. ;-) –
Total git-ssh-newbie ici mais pouvez-vous utiliser scp avec github alors? – Koen
Non, l'interface git-ssh de github est programmée pour que vous n'ayez jamais de shell/console ssh. Il ne peut exécuter que le processus git côté serveur. –
Il est un peu tard, mais cette réponse pourrait aider quelqu'un. Je voulais le savoir parce que je voulais être en mesure de pousser une fonctionnalité en cours/bug/quoi que ce soit et travailler à partir du même point sur un autre ordinateur.
Ce qui fonctionne pour moi est de valider mon code en cours (dans une branche sur laquelle je travaille seul). Quand je reçois à mon autre ordinateur, faire une traction, puis annuler la commettras avec:
git reset --soft HEAD^
continuer à travailler comme vous, avec tous vos en cours là-bas, des changements non engagés et unstaged.
Espérons que ça aide.
Lorsque j'essaie de faire cela, l'Origin maintient toujours la validation, qui n'a pas été validée. Proche mais pas de cigare pour moi. – rezwits
@rezwits Oui, la télécommande le garde, mais il est assez facile de supprimer simplement la branche temporaire de l'origine. –
en fait c'est ce que j'ai fait! – rezwits
Ce qui suit ne fonctionne pas avec la dissimulation, mais avec les modifications non validées dans le répertoire de travail. Il crée une branche, autocommits tous les changements actuels et pousse à la télécommande:
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 ..."
}
utilisation comme:
commit_and_push_ my-temp-branch
commit_and_push_
Il semble y avoir un truc très propre à résoudre ce problème. vous pouvez utiliser git diff > file.diff (et valider le fichier), puis restaurer les modifications en utilisant git apply file.diff (de n'importe où) pour obtenir le même résultat.On a également expliqué here également.
si vous avez des fichiers non-suivis: 1. git add. 2. git diff HEAD> file.diff – trickpatty
Utilisez simplement Dropbox comme ce gars-là. De cette façon, vous n'avez pas à vous soucier de pousser des cachettes puisque tout votre code serait sauvegardé.
Avant que quelqu'un ait une réaction instinctive, je ne dis pas d'utiliser Dropbox au lieu de Github, mais de stocker du code qui n'est pas prêt pour un commit dans Dropbox qui serait toujours sous version contrôler localement. –
il faudra trop de temps pour copier tout le projet sur le cloud distant. –
Vous pouvez récupérer la dernière sauvegarde à partir d'une télécommande git, mais pas dans votre stock, seulement dans une autre référence. Quelque chose comme 'git va chercher un peu plus à distance + refs/stash: refs/remotes/some-remote/stash' le' git stash applique un peu distant/stash'. Mais vous ne pouvez pas obtenir des cachettes plus anciennes parce qu'elles sont stockées dans le reflog qui n'est pas fetchable. Voir http://stackoverflow.com/questions/2248680/can-i-fetch-a-stash-from-a-remote-repo-into-a-local-branch/29839687#answer-29839687 – sj26