En git, ¿es posible crear un alijo, enviar el alijo a un repositorio remoto, recuperar el alijo en otra computadora y aplicar el alijo?¿Es posible enviar un alijo de git a un repositorio remoto?
O son mis opciones:
No es posible obtenerlo a través de fetch, el espejo refspec es fetch = +refs/*:refs/*, y aunque stash es refs/stash no se envía. ¡Un refs/stash:refs/stash explícito tampoco tiene efecto!
De todos modos, sería confuso, ya que no obtendría todos los stashes, solo el último; la lista de stashes es reflog del ref refs/stashes.
Me gustaría ir con el segundo enfoque, aunque no tengo idea de por qué no puedes comprometerlo con la rama principal/presentada. También es posible hacer cherry-picking.
No hay ninguna razón técnica para no cometer al maestro/destacados, sólo que quiero decir "Esto no es un verdadero cometer, es sólo el ahorro de mi trabajo para que pueda obtener en otra máquina". –
Llego un poco tarde a la fiesta, pero creo que encontré algo que me funciona con respecto a esto y también podría serlo si sus circunstancias son las mismas o similares.
Estoy trabajando en una función en su propia sucursal. La rama no se fusionó con la maestra y se presionó hasta que finalizó o realicé confirmaciones que me siento cómodo mostrando al público. Así que lo que hago cuando quiero transferir etapas no cambia a otro equipo es:
[non-commit] FOR TRANSFER ONLY", con el contenido que desea transferido.Después, realice:
git pull ssh+git://<username>@<domain>/path/to/project/ rb:lb
La URL puede ser diferente para usted si accede a su repositorio de una manera diferente. Esto generará cambios desde esa URL desde la rama remota "rb" a la rama local "lb". Tenga en cuenta que tengo un servidor ssh ejecutándose en mi propia computadora, y puedo acceder al repositorio de esa manera.
git reset HEAD^ (implica --mixed)
Esto restablece el HEAD para señalar el estado antes de la "[no-confirmación]" comprometerse.
De git-reset (1): "--mixed: restablece el índice, pero no el árbol de trabajo (es decir, los archivos modificados se conservan pero no marcados para comprometerse) [...]"
Por lo tanto, al final tendrá los cambios en los archivos, pero no se realizan confirmaciones maestras y no es necesario un alijo.
Sin embargo, esto requerirá que git reset --hard HEAD^ en el repositorio en el que realizó la "[no compromiso]", ya que la confirmación es basura.
Nota: yo sólo he reescrito esta respuesta con 24 horas más git-fu en mi haber :) En mi historia concha, todo el asunto es ahora tres de una sola línea. Sin embargo, los he descondensado para su conveniencia.
De esta manera, espero que puedan ver cómo hice las cosas, en lugar de tener que copiar/pegar cosas a ciegas.
Aquí está paso por paso.
Supongamos que es fuente en ~/OLDREPO que contiene depósitos. Crear un clon de ensayo que contiene no stashes:
cd ~/OLDREPO
git clone . /tmp/TEST
empujar todas las stashes como ramas temporales:
git send-pack /tmp/TEST $(for sha in $(git rev-list -g stash); \
do echo $sha:refs/heads/stash_$sha; done)
bucle en el extremo receptor de transformar de nuevo 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
limpieza de su ramas temporales si lo va a
git branch -D $(git branch|cut -c3-|grep ^stash_)
Haz una lista git escondite y usted será algo como esto:
[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
En el repositorio original, la misma parecía
[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
st[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
Estoy aprendiendo un mucho en poco tiempo, y creo que probablemente debería simplemente utilizar muchos usos en mi enfoque anterior, que intentaré hacer más adelante. – sehe
Esto funcionó bien para mí, excepto que necesitaba un 'git add .' antes del paso' git stash save ... 'ya que' git stash' se rehúsa a esconder nuevos archivos a menos que se hayan organizado. Además, conectar el resultado de 'git rev-list ...' a 'tac' invierte el orden de los depósitos para que salgan en el mismo orden. –
@AlanKrueger No intenté esta respuesta, pero 'git stash save -u' puede ayudar. – hiroshi
yo sepa toda la idea de escondite es ocultar algo no tan -importante bajo la alfombra local. Nadie debería saber acerca de su basura favorita ;-) El único "pero" es: ¿Pero si me desarrollo en un par de estaciones de trabajo? Entonces scp es mucho mejor.
Algo tan gracioso debería ser un comentario. ;-) –
Total git-ssh-newbie aquí, pero ¿puedes usar scp con github entonces? – Koen
No, la interfaz git-ssh de github está programada para que nunca tengas una consola/shell ssh. Solo puede ejecutar el proceso git del lado del servidor. –
Es un poco tarde, pero esta respuesta podría ayudar a alguien. Quería saber esto porque quería poder insertar una característica en progreso/error/lo que sea y trabajar desde el mismo punto en otra computadora.
Lo que funciona para mí es comprometer mi código en progreso (en una rama en la que estoy trabajando solo). Cuando llego a mi otro ordenador, hacer un tirón, a continuación, deshacer el envío de datos con:
git reset --soft HEAD^
seguir trabajando como eras, con todos los cambios en curso No, no comprometida, y no escénica.
Espero que ayude.
Cuando intento hacer esto, el Origen aún mantiene el Compromiso, que no fue confirmado. Cerca pero no cigarro para mí. – rezwits
@rezwits Sí, el control remoto lo conserva, pero es bastante fácil simplemente eliminar la bifurcación temporal del origen. –
¡de hecho eso es lo que he estado haciendo! – rezwits
Lo siguiente no funciona con el alijo, pero con los cambios no confirmados en el directorio de trabajo. Se crea una rama, autocommits todos los cambios actuales, y empuja a la distancia:
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 ..."
}
Uso como:
commit_and_push_ my-temp-branch
commit_and_push_
Parece que hay un truco muy ordenada para resolver esto. puede usar git diff > file.diff (y confirmar el archivo), luego restaure los cambios usando git apply file.diff (desde cualquier lugar) para lograr el mismo resultado.
Esto se explicó here también.
si tiene archivos sin seguimiento: 1. git add. 2. git diff HEAD> file.diff – trickpatty
Simplemente usa Dropbox como lo hizo este tipo. De esta forma, no tendrá que preocuparse por empujar los escondites, ya que se hará una copia de seguridad de todo su código.
Antes de que alguien tenga una reacción instintiva, no estoy diciendo usar Dropbox en lugar de Github, sino almacenar código que no está listo para una confirmación en Dropbox que aún estaría en la versión controlar localmente –
tardará demasiado tiempo en copiar todo el proyecto a la nube remota. –
Puedes buscar el último escondite de un control remoto git, pero no en tu escondite, solo en otra referencia. Algo así como 'git fetch some-remote + refs/stash: refs/remotes/some-remote/stash' el' git stash apply some-remote/stash'. Pero no se pueden acumular depósitos porque están almacenados en el reflog, que no es extraíble. Ver http://stackoverflow.com/questions/2248680/can-i-fetch-a-stash-from-a-remote-repo-into-a-local-branch/29839687#answer-29839687 – sj26