Tener una comprensión difícil de git -fetch

Es difícil para mí entender los matices de git -fetch. Entiendo que la ejecución de fetch , la selección de enlaces eliminados en la rama de seguimiento local.

Tengo algunas preguntas:

  • ¿Es posible que la rama de seguimiento local no exista? Si es así, ¿será creado automáticamente?

  • ¿Qué sucede si fetch y especifico una rama que no es de seguimiento como destino?

  • La página del manual para git -fetch indica:

     git-fetch <options> <repository> <refspec> 

¿Cómo uso refspec para extraer contenido de mi asistente remoto a una rama de seguimiento remoto? Creo que esto es posible si mi HEAD actual está en master y ejecuto

git fetch origin master

Sin embargo, ¿puedo usar refspec <+?src:dest> para lograr lo mismo? Creo que esto me ayudará a entender mejor los conceptos.

Y una pregunta más:

En mi archivo .git / config hay la siguiente línea para elegir (mostrando solo las líneas relevantes):

 fetch = +refs/heads/*:refs/remotes/origin/* 

¿Alguien puede explicar qué significa exactamente esta línea?

48
01 июля '09 в 20:54 2009-07-01 20:54 Parag se establece el 01 de julio de 2009 a las 20:54 2009-07-01 20:54
@ 4 respuestas

Primero, no existe tal concepto de sucursales de seguimiento local, solo sucursales de seguimiento remoto. Por lo tanto, origen / maestro es la rama de seguimiento remoto para maestro en el registro de origen .

Por lo general, ejecuta git fetch $ remote , que actualiza todas sus sucursales de seguimiento remoto y crea otras nuevas si es necesario.

Sin embargo, también puede especificar refspec, pero esto no afectará sus sucursales de seguimiento remoto, sino que seleccionará la rama especificada y la guardará en FETCH_HEAD, a menos que especifique un destinatario. En general, no quieres meterte con eso.

Por fin

 fetch = +refs/heads/*:refs/remotes/origin/* 

Eso significa que si lo haces

 git fetch origin 

Esto realmente hará:

 git fetch origin +refs/heads/*:refs/remotes/origin/* 

Esto significa que la cabecera / foobar remota será local / source / foobar remota , y el signo más significa que se actualizarán, incluso si no son rápidos, hacia adelante.

Quizás lo que considera como una rama de seguimiento está relacionado con la configuración de git pull and merge.

54
01 июля '09 в 22:18 2009-07-01 22:18 La respuesta la da FelipeC el 1 de julio de 2009 a las 10:18 pm 2009-07-01 22:18

felipec respondió la mayoría de las preguntas que están cubiertas en su respuesta .

Algunas restantes (la mayoría tomadas de la página de manual de git fetch , que está un poco desactualizada en algunos lugares, desafortunadamente):

border=0
  • Si no existe una rama de seguimiento remoto (una rama que rastrea una rama en un repositorio remoto), se creará.

  • La rama entrante ( <dst> en [+]<src>:<dst> ) no debe estar en los remotes/<remote>/ namespace. Por ejemplo, para duplicar los repositorios ( git clone --mirror ) refspec es de 1 a 1. En los viejos tiempos, antes de una disposición separada de las consolas (hasta remotes/<remote>/ namespace para enlaces de seguimiento remotos), la rama principal se seleccionaba en las sucursales con el nombre origen . Incluso las etiquetas de tiempo actuales se seleccionan directamente en las tags/ espacio de nombres cuando se duplican.

  • Si selecciona una rama (el lado derecho refspec <src>:<dst> existe, Git verificará si la descarga llevará a un avance rápido, es decir, si el estado actual en <dst> es un antecesor del estado en <src> en este remoto repositorios: si este no es el caso, y no está utilizando la --force -f / --force para git -fetch o el prefijo refspec con '+' (use +<src>:<dst> refspec) fetch se negaría a actualizar esta rama.

  • git fetch origin master equivalente a git fetch origin master: y no git fetch origin master:master ; almacena el valor resultante de la rama principal (origen remoto) en FETCH_HEAD, y no en la rama principal o remotos remotes/origin/master seguimiento remotes/origin/master . Puede ser seguido por git merge FETCH_HEAD . Por lo general, no se usa directamente, pero como parte de un solo clic sin configurar una rama de seguimiento remoto: git pull <URL> <branch> .

  • +refs/heads/*:refs/remotes/origin/* como el valor para la configuración de la configuración remote.origin.fetch significa que cada rama (ref en refs/heads/ namespace) en el inicio remoto se selecciona en la rama de seguimiento remoto correspondiente correspondiente nombres refs/remotes/origin/ , por ejemplo. la rama principal en la fuente (es decir, refs/heads/master ref) se cargará en la rama de seguimiento / maestro de origen remoto (es decir, refs/remotes/origin/master ref). El prefijo "+" significa que la muestra tendrá éxito incluso en el caso sin un reenvío rápido, lo que significa que la rama en el servidor remoto se restablece o rebobina (se restablece a algún estado en el pasado) o se modifica de otro modo.

Nota al margen: es posible que desee utilizar un nivel superior de git remote para administrar repositorios remotos y obtener actualizaciones.

20
01 июля '09 в 23:44 2009-07-01 23:44 Jakub Narębski da la respuesta el 1 de julio de 2009 a las 23:44 2009-07-01 23:44

Tenga en cuenta que el soporte principal para Git es ahora (Git 2.1, agosto de 2014) agregó esta explicación a git fetch :
( commit fcb14b0 Junio ​​C Hamano ( gitster ) :

RAMAS CONFIGURADAS DE SEGUIMIENTO REMOTO

A menudo, interactúa con el mismo repositorio remoto de forma regular y se extrae de él repetidamente. Para rastrear el progreso de dicho repositorio remoto, git fetch permite configurar el remote.<repository>.fetch variables de configuración.

Por lo general, tal variable podría tener este aspecto:

 [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* 

Esta configuración se utiliza de dos maneras:

  • Cuando git fetch inicia git fetch sin especificar qué ramas y / o etiquetas se extraerán en la línea de comandos, por ejemplo. Los valores git fetch origin o git fetch , remote.<repository>.fetch se utilizan como refspecs --- determinan qué refs para obtener y qué enlaces locales actualizar .
    En el ejemplo anterior, se seleccionarán todas las ramas que existen en el origin (es decir, cualquier referencia que coincida con el lado izquierdo del valor, refs/heads/* ) y actualicen las ramas de seguimiento remoto correspondientes en la jerarquía refs/remotes/origin/* .

  • Cuando git fetch ejecuta con ramas y / o etiquetas explícitas para extracción en la línea de comandos, por ejemplo. git fetch origin master , <refspec> , especificado en la línea de comando, determina lo que debe extraerse (por ejemplo, master en el ejemplo, que es la abreviatura de master: que a su vez significa "fetching" master ', pero no digo que la rama de seguimiento remoto se actualice con ella desde la línea de comando "), y el comando de ejemplo solo extraerá la 'rama master .
    Los valores de remote.<repository>.fetch determinan qué rama del seguimiento remoto, si existe, se actualiza.
    Cuando se usan de esta manera, los valores de remote.<repository>.fetch no afectan la elección de lo que recibe (es decir, los valores no se usan como refspecs cuando los refspecs están listados en la línea de comando); se utilizan solo para determinar dónde se almacenan los refs que se recuperan, actuando como una pantalla.

4
02 авг. La respuesta se da VonC 02 ago. 2014-08-02 21:00 '14 a las 21:00 2014-08-02 21:00

Tenga en cuenta también que con Git 2.5+ (Q2 2015) git merge FETCH_HEAD puede combinar varias git merge FETCH_HEAD git .

Ver commit d45366e Junio ​​C Hamano ( gitster ) , 26 de marzo de 2015.
(fusionado Junio ​​C Hamano - gitster - para cometer bcd1ecd , 19 de mayo de 2015)

" git merge FETCH_HEAD " aprendió que el anterior " git fetch " podría ser la creación de Octopus merge, es decir, registro de varias ramas que no están marcadas como "no para fusionar"; esto nos permite perder el antiguo git merge <msg> HEAD $commits... " git merge <msg> HEAD $commits... " en la implementación del script " git pull "; La sintaxis de estilo antiguo ahora puede ser obsoleta.

ahora se menciona git merge doc :

Si FETCH_HEAD especifica FETCH_HEAD (y no hay otro compromiso), las ramas registradas en el .git/FETCH_HEAD llamada de git fetch anterior para combinar se fusionan en la rama actual .


Git 2.13 (Q2 2017) elimina oficialmente la antigua sintaxis de git merge .
Ver commit b439165 (26 de marzo de 2015) Junio ​​C Hamano ( gitster ) .
(la fusión de Junio ​​S Hamano - gitster - in commit 1fdbfc4 , 30 de marzo de 2017

merge : soltar ' git merge <message> HEAD <commit> ' sintaxis

Detenga el soporte para la sintaxis " git merge <message> HEAD <commit> " que ha quedado en desuso desde octubre de 2007 y emite una advertencia sobre el abandono de la versión 2.5.0.

Esto significa que en el estilo antiguo " 'git merge <msg> HEAD <commit>' is deprecated. " 'git merge <msg> HEAD <commit>' is deprecated. Aparece un mensaje de advertencia.

2
24 мая '15 в 19:56 2015-05-24 19:56 VonC da la respuesta el 24 de mayo de 2015 a las 19:56 2015-05-24 19:56

Otras preguntas sobre tags o Haz una pregunta