¿Cómo presionar a un repository Git no desnudo?

Normalmente trabajo en un servidor remoto a través de ssh (pantalla y vim), donde tengo un repository de Git. A veces no estoy conectado, así que tengo un repository separado (clonado desde mi control remoto) en mi computadora portátil.

Sin embargo, no puedo extraer de este repository en el lado remoto porque generalmente estoy detrás de un firewall o no tengo una IP pública.

He leído que debería presionar solo a un repository desnudo. ¿Cómo debo enviar mis cambios a mi repository remoto?

receive.denyCurrentBranch updateInstead

Esta opción se agregó en Git 2.3 y hace que el servidor actualice su árbol de trabajo si está limpio.

Por lo tanto, si se asegura de que siempre se compromete antes de tirar localmente, y mantener un árbol de trabajo limpio en el servidor (lo que debe hacer para evitar tener conflictos de fusión), entonces esta opción es una buena solución.

Uso de muestra:

 git init server cd server touch a git add . git commit -m 0 git config --local receive.denyCurrentBranch updateInstead cd .. git clone server local cd local touch b git add . git commit -m 1 git push origin master:master cd ../server ls 

Salida:

 a b 

Mejor opción

Probablemente, la forma más segura, menos confusa y más segura de acceder a su repository remoto no específico es pasar a las sucursales dedicadas del control remoto que representan las twigs de su computadora portátil.

Veamos el caso más simple y supongamos que tiene solo una twig en cada repository: maestro. Cuando presiona hacia el repository remoto desde su computadora portátil, en lugar de presionar master -> master, presione master -> laptop-master (o un nombre similar). De esta forma, la inserción no afecta a la twig maestra que está actualmente desprotegida en el repository remoto. Para hacer esto desde la computadora portátil, el comando es bastante simple:

 git push origin master:laptop-master 

Esto significa que la twig principal local se insertará en la twig denominada “laptop-master” en el repository remoto. En su repository remoto, tendrá una nueva twig llamada “laptop-master” que luego podrá fusionar en su maestro remoto cuando esté listo.

Opción alternativa

También es posible presionar master -> master, pero no se recomienda presionar a la twig actualmente desprotegida de un repository non-bare, porque puede ser confuso si no entiendes lo que está sucediendo. Esto se debe a que si presiona una sucursal retirada no se actualiza el árbol de trabajo, por lo tanto, si se comprueba el git status en la twig extraída que se insertó, se mostrarán exactamente las diferencias opuestas a las que se presionaron más recientemente. Sería especialmente confuso si el árbol de trabajo estuviera sucio antes de que se realizara el empuje, que es una gran razón por la cual no se recomienda.

Si quieres probar simplemente presionando master -> master, entonces el comando es simplemente:

 git push origin 

Pero cuando regrese al repository remoto, lo más probable es que quiera hacer un git reset --hard HEAD para sincronizar el árbol de trabajo con el contenido que se envió. Esto puede ser peligroso , porque si hay cambios no confirmados en el árbol de trabajo remoto que desea conservar, se eliminarán. ¡Asegúrese de saber cuáles son las consecuencias de esto antes de probarlo, o al menos hacer primero una copia de seguridad!

EDITAR Desde Git 2.3, puede usar “push-to-deploy” git push: https://github.com/blog/1957-git-2-3-has-been-released . Pero empujar a una twig separada y luego fusionar suele ser mejor, ya que realiza una fusión real (por lo tanto, funciona con cambios no confirmados como lo hace merge).

Yo sugeriría tener un repository simple y un repository de trabajo local (no desnudo) en su servidor. Podrías impulsar los cambios de la computadora portátil al repo al descubierto del servidor y luego pasar de ese repository desnudo al repository de trabajo del servidor. La razón por la que digo esto es porque es posible que tenga muchas twigs completas / incompletas en el servidor que deseará replicar en la computadora portátil.

De esta forma, no tiene que preocuparse por el estado de la sucursal desprotegida en el repository de trabajo del servidor mientras realiza cambios en el servidor.

Otra opción es configurar un túnel ssh inverso para que pueda tirar en lugar de empujar.

 # start the tunnel from the natted box you wish to pull from (local) $ ssh -R 1234:localhost:22 user@remote # on the other box (remote) $ git remote add other-side ssh://user@localhost:1234/the/repo $ git pull other-side 

Y si quieres que el túnel se ejecute en segundo plano

 $ ssh -fNnR 1234:localhost:22 user@remote 

Tu puedes hacer:

$git config --bool core.bare true

esto se puede hacer en un repository central o no, de modo que acepte cualquier archivo que sea enviado desde un repository no desnudo. Si haces esto en un repository no desnudo, entonces no podemos enviar ningún archivo desde un repository no desnudo al simple.

Si está practicando GIT creando repo central y no bare en PC, es posible que no muestre los archivos enviados en algunas PC, pero se ha insertado. puedes verificarlo ejecutando.

$git log en el repository central.

Además de presionar a GitHub, mostrará los archivos allí.