git pull maestro remoto en cabeza separada

Esto me ha estado molestando acerca de git. Tengo un repository con múltiples controles remotos, y necesito aplicar revisiones a las twigs maestras de los controles remotos. Entonces, trato de hacer:

git fetch remote1 master git checkout remote1/master 

Pero, siempre termino en un estado de cabeza separada. ¿Cuál es la forma correcta de verificar el maestro de un control remoto y aplicar un parche?

Ninguno de esos commands te dará una cabeza separada. ¿Hay algo más que estés haciendo que no hayas anotado en tu pregunta?

 git fetch remote1 

Esto obtendrá cualquier cosa que coincida con el refspec pnetworkingeterminado para remote1 . Eso normalmente significa todas las twigs en remote1 less que lo hayas configurado de manera diferente.

 git fetch remote1 master 

El command anterior remote1 master de remote1 y lo almacena como FETCH_HEAD .

 git pull remote1/master 

Este command generará un error porque remote1/master no es el nombre de un repository.

Hay algunas maneras en que puede abordar el problema, pero realmente depende de lo que está tratando de lograr. El enfoque típico sería crear una sucursal local para la sucursal remota que desea actualizar y fusionar la sucursal correspondiente:

 git checkout -b r1-master remote1/master git merge other/master git push 

Sin embargo, no está claro si se trata de un flujo de trabajo aceptable para usted. ¿Puedes publicar más información sobre lo que estás tratando de lograr?

Actualizar

Gracias por actualizar su pregunta con los commands reales utilizados.

 git fetch remote1 master 

El command anterior toma el contenido más reciente de maestro y lo almacena en FETCH_HEAD . Desea dejar el master aquí y deje que Git actualice sus references remotas: git fetch remote1 . En este puntero, remote1/master debe estar actualizado con lo que hay en el server.

 git checkout remote1/master 

Este es el command que le da un HEAD separado. Las references remotas no se tratan de la misma manera que las twigs locales (refs en refs/heads ). Cuando compras una reference remota, Git te pone en un estado HEAD separado. Creo que la idea detrás de esto es evitar que corrompan su visión de las sucursales remotas. Los refs remotos están ahí para servir como una instantánea del estado del repository remoto la última vez que fue a search. Permitirle comprometerse con ellos arruinaría esa vista. Las sucursales locales son donde se deben realizar ediciones.

Hagamos un par de suposiciones. En primer lugar, remote1 que remote1 no es de origin y que ha agregado este control remoto para interactuar con un repository diferente al primario. En segundo lugar, supongo que tiene la capacidad de enviar código a remote1 .

Antes de ir más lejos, push.default que push.default se establezca en un valor razonable . Ejecute la git config --global push.default . Si no se devuelve nada, o dice que matching , entonces vamos a cambiarlo. La configuration pnetworkingeterminada ( matching ) intentará actualizar todas las references en un impulso para un control remoto en particular. Esto tiene el efecto secundario de eliminar el trabajo de las personas si no mantiene actualizadas las versiones locales de sus sucursales. Un mejor valor pnetworkingeterminado es el upstream , que solo impulsará la twig en la que se encuentra. Establecerlo con:

 git config --global push.default upstream 

La forma típica de agregar un parche en Git es crear una bifurcación, crear su parche, fusionarlo en la representación local de la sucursal remota y luego enviar el resultado a la sucursal remota.

Comencemos creando una twig local del maestro remoto:

 git checkout -b r1-master remote1/master 

Ahora tenemos una twig local llamada r1-master que podemos actualizar ( HEAD no se desconectará en esta twig).

A continuación, haz tu trabajo. Esto generalmente implica crear otra twig y agregarle su serie de parches:

 git checkout -b fix-bugs r1-master # Edit and commit 

A continuación, deberá volver a ejecutar r1-master . Al hacer los cambios, alguien podría haber introducido nuevos commits en remote1/master , así que remote1/master estar actualizados:

 git fetch remote1 

Luego, combine en la twig de reparación de errores:

 git merge fix-bugs 

Esto abrirá un editor. Agregue un post de logging sensato sobre lo que corrige la fusión, y luego guárdelo y salga.

En este punto, r1-master tiene su solución, pero no está en el server remoto. Necesitamos empujar nuestro arreglo recientemente introducido al server remoto:

 git push 

En este punto, r1-master y remote1/master deberían apuntar a lo mismo, y el server remoto ha sido actualizado con su corrección.

Otra ayuda

Por lo que vale, parece que eres nuevo en Git, así que déjame señalarte un par de tutoriales. El primero es Try Git . Me gusta porque puedes probar los commands allí mismo en la página web, pero no es muy profundo. Git Immersion va más en profundidad y tiene una excelente presentación de los conceptos detrás de Git. Cheatsheet Git de NDP Software también es una excelente reference sobre cómo los commands afectan el repository local y remoto. Finalmente, Pro Git es un buen libro para comenzar. La versión en línea es gratis.

git fetch remote1 master searchá la twig principal del control remoto y la almacenará en FETCH_HEAD , no en remote1/master . – Simplemente quieres que git fetch remote1 , o git fetch --all .

git checkout remote1/master siempre lo colocará en modo de cabezales separados, porque no especificó una twig local. – Quieres algo así como git checkout -b master remote1/master .

Por favor, lea la git help fetch y git help checkout .