Tener dificultades para entender git-fetch

Felipec ha respondido a la mayoría de las cuestiones en cuestión en su respuesta.

Unos pocos restantes (la mayoría tomados de git fetch manpage; que es un poco anticuado en algunos lugares, desafortunadamente):

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

• La rama en la que se obtiene (el <dst> en [+]<src>:<dst>) no necesita residir en remotes/<remote>/ espacio de nombres. Por ejemplo, para los repositorios de reflejo (git clone --mirror) refspec es 1 a 1. En los viejos tiempos antes de separate remotes layout (antes de remotes/<remote>/ namespace for remote-tracking refs) master branch se obtenía en la rama llamada origin. Incluso actualmente las etiquetas se obtienen directamente en el espacio de nombres tags/ en forma de reflejo.

• Si la rama a la que está buscando (el lado derecho de refspec <src>:<dst> existe, Git verificaría si la descarga resultaría en un avance rápido, es decir, si el estado actual en <dst> es el antepasado del estado en <src> en un repositorio remoto dado. Si no lo es, y no usas -f/--force option to git-fetch, or prefix refspec with '+' (use +<src>:<dst> refspec) fetch would refuse to update that branch.

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

• +refs/heads/*:refs/remotes/origin/* como valor para remoto.origen.fetch variable de configuración significa que cada rama (ref en refs/heads/ espacio de nombres) en remote origin se obtiene en la rama de seguimiento remoto respectivamente llamada en refs/remotes/origin/ espacio de nombres, por ejemplo, master branch en origin (es decir, refs/heads/master ref) se obtiene en origin/master rama de seguimiento remoto (es decir, refs/remotes/origin/master ref). El prefijo ' + ' significa que fetch tendría éxito incluso en caso de no avance rápido, lo que significa que cuando la rama en remoto se rebasa, o rebobina (restablece a algún estado en el pasado) o se modifica de otra manera.

Sidenote: Probablemente quieras usar el comando git remote de mayor nivel para administrar repositorios remotos y obtener actualizaciones.

Tenga en cuenta que el mantenedor principal de Git ahora (Git 2.1, agosto de 2014) ha agregado esta explicación para git fetch:
(Véase commit fcb14b0 by Junio C Hamano (gitster):

RAMAS DE SEGUIMIENTO REMOTO CONFIGURADAS

A menudo interactúa con el mismo repositorio remoto obteniendo de él de forma regular y repetida. Para realizar un seguimiento del progreso de dicho repositorio remoto, git fetch le permite configurar {[4] } variable.

Típicamente tal variable puede tener este aspecto:

[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 comandos, por ejemplo, git fetch origin o git fetch, remote.<repository>.fetch los valores se usan como refspec ---especifican qué refs buscar y qué refs locales actualizar.
  El ejemplo anterior buscará todas las ramas que existen en origin (es decir, cualquier ref que coincida con el lado izquierdo del valor, refs/heads/*) y actualice las ramas de seguimiento remoto correspondientes en la jerarquía refs/remotes/origin/*.

• Cuando git fetch se ejecuta con ramas explícitas y / o etiquetas para obtener en la línea de comandos, por ejemplo, git fetch origin master, los <refspec> s dados en la línea de comandos determinan qué se debe obtener (por ejemplo, master en el ejemplo, que es una abreviación para master:, que a su vez significa "obtener la rama 'master' pero no digo explícitamente qué rama de seguimiento remoto actualice con él desde la línea de comandos"), y el comando de ejemplo obtendrá solo la rama 'master'.
  Los valores remote.<repository>.fetch determinan qué rama de seguimiento remoto, en su caso, se actualiza.
  Cuando se usa de esta manera, los valores remote.<repository>.fetch no tienen ningún efecto en decidir lo que se obtiene (es decir, los valores no se usan como refspecs cuando la línea de comandos enumera refspecs); solo se usan para decidir donde las refs que se obtienen se almacenan actuando como un asignación.

Tenga en cuenta también que, con Git 2.5+ (Q2 2015), git merge FETCH_HEADpuede combinar múltiples de git fetch.

Véase commit d45366e by Junio C Hamano (gitster), 26 Mar 2015.
^{(Merged by Junio C Hamano -- gitster -- in commit bcd1ecd, 19 May 2015)}

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

El git merge doc ahora mencione:

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

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

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

Deja de soportar la sintaxis "git merge <message> HEAD <commit> " que tiene ha estado en desuso desde octubre de 2007, y emite un mensaje de advertencia de desuso desde la versión 2.5.0.

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