repositorio - git remote

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

Question

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

Sin embargo, no puedo extraer de este repositorio 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 repositorio desnudo. ¿Cómo debo enviar mis cambios a mi repositorio remoto?

Answer 1

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

Answer 2

Tu puedes hacer:

$git config --bool core.bare true

esto se puede hacer en un repositorio central o no, de modo que acepte cualquier archivo que sea enviado desde un repositorio no desnudo. Si haces esto en un repositorio no desnudo, entonces no podemos enviar ningún archivo desde un repositorio 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 repositorio central.

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

Answer 3

Yo sugeriría tener un repositorio simple y un repositorio 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 repositorio desnudo al repositorio de trabajo del servidor. La razón por la que digo esto es porque es posible que tenga muchas ramas 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 repositorio de trabajo del servidor mientras realiza cambios en el servidor.

Answer 4

La actualización receive.denyCurrentBranchEn cambio , agregada en Git 2.3 , también actualiza el árbol de trabajo del servidor 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

Answer 5

Mejor opción

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

Veamos el caso más simple y supongamos que tiene solo una rama en cada repositorio: maestro. Cuando presiona hacia el repositorio 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 rama maestra que está actualmente desprotegida en el repositorio remoto. Para hacer esto desde la computadora portátil, el comando es bastante simple:

git push origin master:laptop-master

Esto significa que la rama principal local se insertará en la rama denominada "laptop-master" en el repositorio remoto. En su repositorio remoto, tendrá una nueva rama 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 rama actualmente desprotegida de un repositorio 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 rama 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 repositorio 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 rama 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).