¿Git no clona todas las ramas en los clones subsiguientes?

Question

Tengo algunos problemas con Git al usar repositorios y ramas clonados y de alguna manera no es posible para mí encontrar una respuesta a esto. Permítanme describirlo: tenemos un repositorio básico de Git desnudo de donde todos sacamos y empujamos, ubicado en una máquina Linux local y accesible con ssh. Hice un clon de esto a mi unidad flash USB como esto:

git clone ssh://adahl@gollum//net/repos/netcube/patches.git 

Esto me da por supuesto un clon local con una copia de trabajo en mi unidad de disco USB. Me cd a esto y ver algunas ramas en este clon a continuación:

cd patches 
git branch -a 
* master 
    remotes/origin/HEAD -> origin/master 
    remotes/origin/master 
    remotes/origin/stable 

Hasta aquí todo bien, sin embargo si clonar el repositorio en mi pulgar conducir otra vez en mi portátil se pierde la rama estable. Veo:

cd .. 
git clone patches patches2 

cd patches2 

git branch -a 
* master 
    remotes/origin/HEAD -> origin/master 
    remotes/origin/master 

He intentado varias opciones cuando se clona o una git fetch después de la clonación, nada trae la rama estable a la patches2 repositorio. Supongo que tengo una falta de comprensión aquí y simplemente la uso de la manera incorrecta. ¿Podría alguien señalarme mi error de uso y/o comprensión?

Answer 1

Ver How to clone all remote branches in Git?

Es necesario crear una rama local basada en la rama remota si realmente se desea que sea incluido en un clon. Sin embargo, como no trabajas en sucursales remotas, crearás ramas locales tan pronto como comiences a trabajar en una sucursal. Y antes de eso, realmente no lo necesita en su clon, ya que simplemente puede buscarlo desde el control remoto en cualquier momento.

Sin embargo, si la computadora portátil no tiene conectividad de red, tendrá que crear sucursales locales para todas las sucursales remotas que desee para que se clonen al clonar su repositorio local.

Sin embargo, si tiene conectividad de red, use git remote add origin2 ssh://adahl@gollum//net/repos/netcube/patches.git y luego git fetch origin2 - siéntase libre de reemplazar origin2 con un nombre más significativo.

Answer 2

"origen" es el nombre predeterminado dado al lugar desde el que clonaste el repositorio, que se agrega automáticamente como control remoto (nota: remote solo significa "un repositorio no el actual"; los controles remotos pueden estar en la misma máquina)

En patches, "origen" se refiere al repositorio original en gollum.

En patches2, "origen" se refiere a patches.

Las referencias de seguimiento remoto (las que comienzan con remotes/) no son en realidad sucursales locales, son solo indicadores de la última vez que se sabía que las ramas estaban en el control remoto. Por lo tanto, en patches, tiene referencias de seguimiento remoto para el repositorio original, pero en patches2, solo tiene una referencia de seguimiento remoto para la sucursal local master en patches, porque ahí es donde apunta el origen de patches2.

Puede usar git remote add para agregar el repositorio original como otro control remoto en patches2 después de clonarlo - o puede simplemente clonar nuevamente del repositorio original en lugar de patches.

Answer 3

Además de @ThiefMaster:

me gusta

git clone --mirror 

o

git push --mirror 

actualizar todas (local & remoto) árbitros sucursales y etiquetas

adicional info Como n oted, --mirror realmente replicará el repositorio tal como está, por lo tanto, cambia de forma sobresaliente en el destino. Las ramas que no existen en la fuente serán eliminadas incondicionalmente.

En esencia, es como trabajar con un mando a distancia y haciendo 'git actualización remota --prune', con la diferencia de que las ramas afectadas pueden ser ramas locales, así como referencias remotas '' [1]

@LeSpocky (y otros?)

Ahora, si los cambios desaparecen, nunca generarán problemas de combinación, por lo que es fácil.

--mirror lleva el nombre del concepto de la vida real, por lo que fue diseñado para allanar cualquier diferencia en el objetivo. Si el objetivo no está vacío y se han confirmado los cambios locales, siempre puede recuperarlos a través del reflog de la sucursal local del objetivo (git log -g, git reflog).

Como medida de seguridad general puede have a hook to 'git stash save' in the target.

Tenga en cuenta, sin embargo, que --mirror fue diseñado, bueno, espejo y esta pregunta era, de hecho, sobre cómo replicar todas las ramas a un control remoto desnudo. :)

[1] (los refs están ahí, pero las definiciones remotas no se copian; si lo desea, haga una copia manual de .git/config a .git/config en el destino de inserción)

Answer 4

$ git remote update 
$ git pull --all