crear - git stash

Tener dificultades para entender git-fetch

Question

Me está costando entender los matices de git-fetch. Entiendo que al hacer una fetch , busca referencias remotas en una sucursal de seguimiento local.

Sin embargo, tengo algunas preguntas:

1. ¿Es posible que no exista una sucursal de seguimiento local? Si es así, ¿se creará automáticamente?

2. ¿Qué pasará si realizo una fetch y especifico una rama sin seguimiento como destino?

3. La página man para git-fetch especifica:

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

¿Cómo utilizaré el refspec para obtener contenidos de mi maestro remoto en su rama de seguimiento remoto? Creo que esto puede ser posible si mi HEAD actual está en master y corro

git fetch origin master

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

Y una pregunta más:

Mi archivo .git / config tiene la siguiente línea para buscar (muestra solo las líneas relevantes):

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

¿Puede alguien explicar por favor qué significa exactamente esta línea?

Answer 1

respondió la mayoría de los temas en cuestión en su respuesta .

Quedan unos pocos (la mayoría de ellos tomados de la página de búsqueda de git , que está un poco anticuada en algunos lugares, desafortunadamente):

• Si la rama de seguimiento remoto (rama que rastrea alguna rama en algún repositorio remoto) no existe, se crearía.

• La rama a la que accede (la <dst> en [+]<src>:<dst> ) no necesita residir en remotes/<remote>/ namespace. Por ejemplo para duplicar repositorios ( git clone --mirror ) refspec es 1 a 1. En los viejos tiempos antes del diseño de remotos separados (antes de los remotes/<remote>/ espacio de nombres para refs de rastreo remoto) la rama maestra fue captada en la rama llamada origen . Incluso las etiquetas actuales se captan directamente en tags/ espacios de nombres en forma de reflejo.

• Si la bifurcación está captando (el lado derecho de refspec <src>:<dst> existe, Git verificaría si la descarga daría como resultado el avance rápido, es decir, si el estado actual en <dst> es antecesor de estado en <src> en un repositorio remoto dado. Si no lo es, y no usa la opción -f / --force para git-fetch, o prefija refspec con ''+'' (use +<src>:<dst> refspec) fetch se negaría a actualizar esa rama.

• git fetch origin master es equivalente al git fetch origin master: no a git fetch origin master:master ; almacena el valor obtenido de la rama maestra (de origen remoto) en FETCH_HEAD , y no en la rama maestra o remotos de seguimiento remotes/origin/master rama remotes/origin/master . Puede ser seguido por git merge FETCH_HEAD . Por lo general, no se usa directamente, sino como parte de una extracción única sin configurar la rama de seguimiento remoto: git pull <URL> <branch> .

• +refs/heads/*:refs/remotes/origin/* como valor para la variable de configuración remote.origin.fetch significa que cada bifurcación (ref en refs/heads/ namespace) en origen remoto se busca en la rama de rastreo remoto con nombre respectivo en refs/remotes/origin/ namespace, p. ej., branch principal en origen (es decir, refs/heads/master ref) se captarán en la derivación de rastreo remoto de origen / maestro (es decir, refs/remotes/origin/master ref). El prefijo ''+'' significa que la recuperación tendrá éxito incluso en caso de avance no rápido, lo que significa que la bifurcación en el control remoto se vuelve a establecer o rebobinar (restablecer a algún estado en el pasado) o modificarse de otra manera.

Nota: probablemente quieras usar un comando remoto de nivel más alto para administrar repositorios remotos y obtener actualizaciones.

Answer 2

En primer lugar, no existe un concepto de ramales de seguimiento local , solo ramales de rastreo remotos . Entonces origin / master es una rama de seguimiento remoto para el maestro en el repositorio de origen .

Por lo general, haces git fetch $ remote, que actualiza todas las ramas de seguimiento remoto y crea nuevas si es necesario.

Sin embargo, también puede especificar un refspec, pero eso no tocará las ramas de seguimiento remoto, sino que buscará la rama que especificó y la guardará en FETCH_HEAD, a menos que especifique un destino. En general, no quieres meterse con esto.

Finalmente,

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

Eso significa que si lo haces

git fetch origin

Realmente lo hará:

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

Lo que significa que las cabezas / foobar remotas serán controles remotos / origen / foobar locales, y el signo más significa que se actualizarán incluso si no son de avance rápido.

Tal vez lo que piensas como una rama de rastreo es algo relacionado con git pull y la configuración de fusión.

Answer 3

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

SUCURSALES CONFIGURADOS DE SEGUIMIENTO REMOTO

A menudo, usted interactúa con el mismo repositorio remoto al obtenerlo de forma regular y repetida. Con el fin de realizar un seguimiento del progreso de un repositorio remoto, git fetch permite configurar variables de configuración remote.<repository>.fetch .

Por lo general, una variable así puede verse así:

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

Esta configuración se usa de dos maneras:

• Cuando git fetch se ejecuta sin especificar qué ramas y / o etiquetas buscar en la línea de comando, por ejemplo, git fetch origin o git fetch , remote.<repository>.fetch valores remote.<repository>.fetch se utilizan como refspecs --- especifican qué referencias buscar y que refs locales para actualizar .
  El ejemplo anterior buscará todas las ramas que existen en el origin (es decir, cualquier referencia que coincida con el lado izquierdo del valor, refs/heads/* ) y actualizará las ramas correspondientes de seguimiento remoto en los refs/remotes/origin/* jerarquía.

• Cuando git fetch se ejecuta con ramas y / o etiquetas explícitas para buscar en la línea de comando, por ejemplo, git fetch origin master , las <refspec> s dadas en la línea de comando determinan qué se debe buscar (por ejemplo, master en el ejemplo, que es una abreviatura para master: que a su vez significa "buscar la rama '' master '' pero no digo explícitamente qué rama de seguimiento remoto actualizar con ella desde la línea de comando"), y el comando de ejemplo solo buscará '' rama master
  Los valores remote.<repository>.fetch determinan qué rama de seguimiento remoto, si hay alguna, se actualiza.
  Cuando se usan de esta manera, los valores remote.<repository>.fetch no tienen ningún efecto al decidir qué se obtiene (es decir, los valores no se usan como refspecs cuando la línea de comando enumera refspecs); solo se usan para decidir dónde se almacenan las referencias que se obtienen al actuar como un mapeo.

Answer 4

Tenga en cuenta también que, con Git 2.5+ (Q2 2015), la git merge FETCH_HEAD puede combinar varias búsquedas de git fetch .

Ver commit d45366e por Junio ​​C Hamano ( gitster ) , 26 de marzo de 2015.
^{(Fusionado por Junio ​​C Hamano - gitster - in commit bcd1ecd , 19 de mayo de 2015)}

" git merge FETCH_HEAD " aprendió que la " git fetch " anterior podría ser para crear una fusión de Octopus, es decir, registrar múltiples ramas que no están marcadas como "no-para-fusionar";
esto nos permite perder una invocación de estilo anterior " git merge <msg> HEAD $commits... " en la implementación del script " git pull "; la sintaxis de estilo antiguo ahora puede ser desaprobada.

El documento de git merge ahora menciona:

Cuando se FETCH_HEAD (y ninguna otra confirmación), las ramas registradas en el archivo .git/FETCH_HEAD por la invocación previa de git fetch para la fusión se fusionan con la rama actual .

Git 2.13 (Q2 2017) oficialmente retira la sintaxis antigua para la git merge .
Ver commit b439165 (26 Mar 2015) por Junio ​​C Hamano ( gitster ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 1fdbfc4 , 30 de marzo de 2017)}

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

Deje de admitir la sintaxis " git merge <message> HEAD <commit> " que ha quedado obsoleta desde octubre de 2007 y emite un mensaje de advertencia de obsolescencia desde v2.5.0.

Eso significa que el mensaje de advertencia de "estilo antiguo '' ''git merge <msg> HEAD <commit>'' is deprecated. " Ya no existe.