git pull --help dice:

En su modo por defecto, git pull » es la abreviatura de git fetch seguido por git merge FETCH_HEAD.

¿Qué es esto FETCH_HEAD, y lo que en realidad se fusionaron durante git pull?

5 Comentarios

  1. 196

    FETCH_HEAD es un breve ref, de seguir la pista de lo que ha sido traída desde el repositorio remoto. git pull primera invoca git fetch, en casos normales a buscar una rama de la remota; FETCH_HEAD puntos a la punta de esta rama (almacena el SHA1 de la confirmación, así como las ramas de hacer). git pull invoca a continuación,git merge, la fusión de FETCH_HEAD en la rama actual.

    El resultado es exactamente lo que cabría esperar: la confirmación en la punta de la correspondiente rama remota se combinan en la confirmación en la punta de la rama actual.

    Esto es un poco como hacer git fetch sin argumentos (o git remote update), la actualización de todas sus sucursales remotas, a continuación, ejecutar git merge origin/<branch>, pero el uso de FETCH_HEAD internamente en lugar de referirse a lo único ref fue capturado, en lugar de la necesidad de dar nombre a las cosas.

    • Tire de mayo de hacer un rebase en lugar de una combinación que si se configura de esa manera.
    • Seguro. He descrito el comportamiento predeterminado, pensando que si alguien lo ha modificado, se sabría que se había modificado. (Para la integridad, el comportamiento es idéntico, en sustitución de merge FETCH_HEAD con rebase FETCH_HEAD).
    • lo siento, creo que se equivoca: como tengo entendido, git fetch actualizaciones (funde) todos los datos de objeto desde el control remoto de almacenamiento, no sólo a brunch. Así que no entiendo de tu respuesta ¿cómo git decide la punta de la rama a punto de FETCH_HEAD. También me pueden encontrar FETCH_HEAD en git documentación (la definición, no ejemplos). La existencia de FETCH_HEAD a mi me parece más como una solución, para hacer git pull trabajo de alguna manera.
    • Alexey: FETCH_HEAD corresponde a la punta de la rama remota especificada por branch.<BRANCH>.merge en el repositorio local de configuración. Así, mientras que fetch hecho recuperar todos los datos de objeto desde el control remoto de almacenamiento, FETCH_HEAD se utiliza para indicar a donde la rama remota seguidos por la rama local ha avanzado. Así que si usted está en el local master rama y ejecutar git fetch, y branch.master.merge puntos a refs/heads/master, entonces FETCH_HEAD tendrá el mismo valor que origin/master inmediatamente después de la operación de captura.
    • FETCH_HEAD se describe en el segundo párrafo de la descripción de git fetch en su página man. Mi respuesta es correcta. Y git fetch sin argumentos hace la actualización de todas las ramas remotas para el remoto predeterminado… pero este definitivamente no es el mismo como la fusión.
    • ¿Qué es FETCH_HEAD si usted recuperar todas las ramas remotas a través de git fetch -a?
    • La punta del seguimiento remoto de la rama actualmente checkedout rama está señalando en el git config. Por favor, consulte larsks’ respuesta en el comentario anterior.
    • Y lo que si usted está separado y hacer un fetch? ¿Qué hacer si tiene un local ref desprotegido, pero no hay un seguimiento remoto de la rama? ¿Cómo se FETCH_HEAD manipulado durante el git fetch en estas circunstancias?
    • No parece que el local estado de la materia? FETCH_HEAD es para mantener el seguimiento de los remoto. Así que cualquier cosa que buscar, que FETCH_HEAD. El local ref/se comprometen a que la desprotegido solo importa cuando llegue a la mezcla.
    • de acuerdo a las respuestas del estado local, no importa. FETCH_HEAD sólo puede guardar una remota sha1. No hace un seguimiento de la remota, como dicen ustedes. Así que cuando fetch tira hacia abajo más de una ref, las respuestas del estado que el seguimiento remoto de la rama determina que de la remota refs se convierte en FETCH_HEAD. Así que mi pregunta sigue en pie.
    • tu pregunta puede ser dirigida por mi recién agregado respuesta a continuación: stackoverflow.com/a/45543739/1290368.
    • Como @Alexey sugiere y @CarstenFührmann aclara más aún, no, FETCH_HEAD no sólo contienen una sola rama. Contiene todo en la rama remota la información que estaba en último lugar.

  2. 15

    La FETCH_HEAD es una referencia a la punta de la última captura, ya que la captura se inició directamente utilizando el comando fetch o como parte de un tirón. El valor actual de FETCH_HEAD se almacena en el .git carpeta en un archivo de nombre, usted lo adivinó, FETCH_HEAD.

    Así que si yo cuestión:

    git fetch https://github.com/ryanmaxwell/Fragaria
    

    FETCH_HEAD puede contener

    3cfda7cfdcf9fb78b44d991f8470df56723658d3        https://github.com/ryanmaxwell/Fragaria
    

    Si tengo la repo remoto configurado como un seguimiento remoto de la rama, a continuación, me pueden seguir a mi a buscar con una mezcla de seguimiento de la rama. Si yo no puedo combinar la punta de la última captura directamente a través de FETCH_HEAD.

    git merge FETCH_HEAD
    
    • Agregar a mis 5 centavos. Lo que me confunde es que mi FETCH_HEAD estaba detrás de la última se compromete, incluso si hacer una nueva captura que se devuelve «no hay cambios» (en eclipse). Creo que la razón es, que todos los cambios desde mi último fetch de mí mismo y fueron empujados al servidor por mí. Para una posterior captura tenía nada que hacer, y ni siquiera la actualización de la FETCH_HEAD. No estoy seguro de si esto es un defecto de GIT o Eclipse Git implementación.
  3. 9

    Como se mencionó en Jonathan respuesta, FETCH_HEAD corresponde al archivo .git/FETCH_HEAD. Normalmente, el archivo tendrá un aspecto como este:

    71f026561ddb57063681109aadd0de5bac26ada9                        branch 'some-branch' of <remote URL>
    669980e32769626587c5f3c45334fb81e5f44c34        not-for-merge   branch 'some-other-branch' of <remote URL>
    b858c89278ab1469c71340eef8cf38cc4ef03fed        not-for-merge   branch 'yet-some-other-branch' of <remote URL>
    

    Nota de cómo todas las ramas, pero están marcados not-for-merge. Lo extraño es la rama en la que estaba desprotegido antes de la recuperación. En resumen: FETCH_HEAD esencialmente corresponde a la versión remota de la rama en la que actualmente se encuentra desprotegido.

  4. 8

    Acabo de descubrir y utilizar FETCH_HEAD. Yo quería una copia local de software de un servidor y me hizo

    git fetch gitserver release_1
    

    gitserver es el nombre de mi máquina que almacena los repositorios git.
    release_1 es una etiqueta para una versión del software. Para mi sorpresa, release_1 entonces estaba en ninguna parte ser encontrado en mi máquina local. Tuve que tipo de

     git tag release_1 FETCH_HEAD 
    

    para completar la copia de la etiquetado de la cadena de confirmaciones (release_1) desde el repositorio remoto para el local. Fetch había encontrado el mando de la etiqueta, copia de la confirmación a mi máquina local, no había, crearon una etiqueta, pero había establecido FETCH_HEAD para el valor de la confirmación, por lo que he podido encontrar y utilizar. A continuación, he usado FETCH_HEAD para crear una etiqueta que coincidía con la etiqueta en el mando a distancia. Que es una ilustración práctica de lo que FETCH_HEAD es y cómo puede ser utilizado, que puede ser útil a alguien preguntando por qué git fetch no hacer lo que sería de esperar ingenuamente.

    Que en mi opinión es mejor evitar para ese propósito y una mejor forma de lograr lo que yo estaba tratando de hacer es

    git fetch gitserver release_1:release_1
    

    es decir, a buscar release_1 y llamar release_1 localmente. (Es fuente:dest, ver https://git-scm.com/book/en/v2/Git-Internals-The-Refspec; sólo en caso de que le gustaría darle un nombre diferente!)

    Usted podría querer usar FETCH_HEAD a veces, cuando:-

    git fetch gitserver bugfix1234
    git cherry-pick FETCH_HEAD
    

    podría ser una buena manera de usar la corrección de error número 1234 de su servidor Git, y dejando Git de recolección de basura para deshacerse de la copia del servidor una vez que la solución ha sido palmitas en su rama actual. (Estoy asumiendo que hay un bonito y limpio etiquetado cometer contiene la totalidad de la corrección de error en el servidor!)

    • Información interesante. +1
    • Gracias. He editado mi post original, escrito cuando descubrí por primera FETCH_HEAD hace un par de años, desde que apareció para fomentar la copia de una etiqueta con FETCH_HEAD en lugar de la fuente:dest sintaxis para refspecs. Esperemos que ahora he dado un mejor ejemplo de cómo la FETCH_HEAD podría ser utilizado.
  5. 3

    git pull es la combinación de una recuperación, seguido por una combinación. Cuando git fetch sucede que las notas de la cabeza confirmación de lo que obtienen en FETCH_HEAD (sólo un archivo con ese nombre .git) Y estos se compromete, a continuación, combina en su directorio de trabajo.

    • ¿a qué te refieres por «jefe de commit de lo que trajo»? Git recupera todo con fetch.
    • a partir de git manual: git-scm.com/docs/git-fetch: los nombres de Los árbitros que se han obtenido, junto con los nombres de objeto que el punto a, se escriben .git/FETCH_HEAD

Dejar respuesta

Please enter your comment!
Please enter your name here