¿Cuál es la diferencia entre 'git pull' y 'git fetch'?

Nota del moderador. Dado que ya se han enviado sesenta y siete respuestas a esta pregunta (algunas de ellas se han eliminado), considere si está agregando algo nuevo antes de enviar otra.

¿Cuáles son las diferencias entre git pull y git fetch ?

10,500
15 нояб. conjunto pupeno 15 nov. 2008-11-15 12:51 '08 a las 12:51 2008-11-15 12:51
@ 46 respuestas
  • 1
  • 2

En los términos más simples, git pull ejecuta un git fetch seguido de git merge .

Puede hacer git fetch en cualquier momento para actualizar las sucursales de seguimiento remoto en refs/remotes/<remote>/ .

Esta operación nunca cambia ninguna de sus propias sucursales locales en los refs/heads y es segura sin cambiar la copia de trabajo. Incluso escuché que la gente ejecuta git fetch periódicamente en un trabajo cron en segundo plano (aunque no lo recomendaría).

Un git pull es lo que haría para actualizar la sucursal local con su versión remota, así como para actualizar otras sucursales de seguimiento remoto.

Documentación Git: Git pull

8755
15 нояб. Respuesta dada por Greg Hewgill el 15 de noviembre. 2008-11-15 12:52 '08 a las 12:52 2008-11-15 12:52
  • Cuando usas pull , Git intenta hacer tu trabajo automáticamente por ti. Esto es sensible al contexto , por lo que Git combinará cualquier confirmación de inserción en la rama en la que está trabajando actualmente. pull automáticamente combina las confirmaciones sin permitirle verlas primero . Si no es muy bueno en la gestión de sus sucursales, puede encontrar conflictos frecuentes.

  • Cuando fetch , Git recopila cualquier confirmación de la rama de destino que no existe en su rama actual, pero los almacena en su repositorio local . Sin embargo, no los combina con tu rama actual . Esto es especialmente útil si necesita actualizar constantemente su repositorio, pero trabaje en lo que puede fallar si actualiza sus archivos. Para integrar los compromisos en la rama principal, utiliza la merge .

border=0
1919
18 авг. respuesta dada por Mouna Cheikhna 18 ago. 2011-08-18 11:53 '11 a las 11:53 2011-08-18 11:53

Es importante contrastar la filosofía de diseño de git con la filosofía de una herramienta de administración de fuentes más tradicional, como SVN.

Subversion fue diseñado y construido usando un modelo cliente / servidor. Hay un repositorio, que es un servidor, y varios clientes pueden extraer el código del servidor, trabajar con él y luego transferirlo de nuevo al servidor. Se supone que el cliente siempre puede ponerse en contacto con el servidor cuando necesita realizar una operación.

Git fue diseñado para admitir un modelo más distribuido sin la necesidad de un repositorio central (aunque puede usarlo si lo desea). Además, git fue diseñado de tal manera que el cliente y el "servidor" no deberían estar en línea al mismo tiempo. Git fue diseñado para que las personas en un enlace no confiable incluso puedan intercambiar códigos por correo electrónico. Puede deshabilitar completamente el trabajo y grabar un CD para intercambiar código a través de git.

Para admitir este modelo, git mantiene un repositorio local con su código, así como un repositorio local adicional que refleja el estado del repositorio remoto. Al almacenar localmente una copia del repositorio remoto, git puede determinar los cambios necesarios, incluso si el repositorio remoto no está disponible. Más adelante, cuando necesite enviar cambios a otra persona, git puede transferirlos como un conjunto de cambios desde el punto en el tiempo conocido por el repositorio remoto.

  • git fetch es un comando que dice: "Lleve mi copia local del repositorio remoto a la fecha".

  • git pull dice: "Traer cambios al repositorio remoto donde guardo mi propio código".

Normalmente, git pull hace esto ejecutando git fetch para actualizar una copia local del repositorio remoto, y luego fusionar los cambios en su propio repositorio de código y posiblemente su copia de trabajo.

Elimine esto para tener en cuenta que a menudo hay al menos tres copias del proyecto en su estación de trabajo. Una copia es su propio repositorio con su propio historial de confirmación. La segunda copia es su copia de trabajo, donde edita y construye. La tercera copia es su copia local "en caché" del repositorio remoto.

1066
31 марта '13 в 21:43 2013-03-31 21:43 la respuesta la da MikeD 31 de marzo de 13 a las 21:43 2013-03-31 21:43
711
09 июня '15 в 16:30 2015-06-09 16:30 la respuesta se da a Contango el 9 de junio de 2015 a las 4:30 p.m. 2015-06-09 16:30

Un uso de git fetch es que el siguiente mensaje le informará sobre cualquier cambio en la rama remota desde la última extracción ... para que pueda verificar antes de realizar la extracción real, que puede cambiar los archivos en su rama actual y ejecutar una copia .

 git fetch git diff ...origin 
437
07 мая '10 в 22:23 2010-05-07 22:23 la respuesta se da a mepster el 7 de mayo de 2010 a las 10:23 AM de 2010-05-07 22:23

Tuve que entender un poco cuál era la diferencia, pero esta es una explicación simple. master en tu localhost es una rama.

Cuando clonas un repositorio, obtienes el repositorio completo para el host local. Esto significa que en este momento tiene el puntero de origen / maestro en la HEAD y el maestro que apunta a la misma HEAD .

cuando comienzas a trabajar y haces esto, transfieres el puntero maestro a HEAD + tus fijaciones. Pero el puntero de origen / maestro aún indica qué era cuando clonaste.

Así, la diferencia será:

  • Si ejecuta git fetch , simplemente extraerá todos los cambios en el repositorio remoto ( GitHub ) y moverá el puntero de inicio / maestro a HEAD . Mientras tanto, el asistente de su sucursal local continuará indicando dónde se encuentra.
  • Si hace git pull , básicamente se extraerá (como se explicó anteriormente) y fusionará cualquier cambio nuevo en la rama principal y moverá el puntero a HEAD .
347
11 мая '12 в 21:37 2012-05-11 21:37 Gerardo da la respuesta el 11 de mayo de '12 a las 21:37 2012-05-11 21:37

A veces una presentación visual ayuda.

2019

25 янв. La respuesta la da el pasajero, 25 de enero. 2016-01-25 20:28 '16 a las 8:28 pm 2016-01-25 20:28

brevemente

git fetch es similar a pull pero no se fusiona. es decir, extrae actualizaciones remotas ( refs y objects ), pero su local permanece sin cambios (es decir, origin/master actualiza el origin/master , pero el master permanece igual).

git pull cae de la consola y se fusiona instantáneamente.

Más

git clone clones repos.

git rebase guarda el material de su rama actual que no está en la rama ascendente al área temporal. Tu hilo ahora es el mismo que antes de que comenzaras tus cambios. Por lo tanto, git pull -rebase los cambios eliminados, rebobinará su sucursal local, repetirá los cambios en la parte superior de la rama actual uno por uno, hasta que esté al día con los últimos desarrollos.

Además, git branch -a le mostrará exactamente lo que está sucediendo con todas sus sucursales, local y remota.

Esta entrada de blog fue útil:

Diferencia entre git pull, git fetch y git clone (y git rebase) - Mike Pierce

y cubre git pull , git fetch , git clone y git rebase .

====

ACTUALIZACIÓN

Pensé que lo estaba actualizando para mostrar cómo lo utilizaste en la práctica.

  1. Actualice su repositorio local desde un dispositivo remoto (pero no se una):

     git fetch 
  2. Después de descargar las actualizaciones, vea las diferencias:

     git diff master origin/master 
  3. Si está satisfecho con estas actualizaciones, fusione:

     git pull 

Notas:

En el paso 2: Para obtener más información sobre las diferencias entre los dispositivos locales y remotos, consulte la Sección: ¿Cómo comparar una sucursal de git local con una sucursal remota?

En el paso 3: Lo más probable es que sea más preciso (por ejemplo, en un repositorio que cambia rápidamente) el git rebase origin . Ver @Justin Ohms Comentar en otra respuesta.

Ver también: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

170
13 апр. Responder Snowcrash 13 de abril 2013-04-13 20:31 '13 a las 8:31 pm 2013-04-13 20:31
 git-pull - obtener y combinar con otro repositorio o una rama local SINOPSIS git pull ... DESCRIPCION Ejecuta el git-fetch  cabeza (s) recuperada (s) en la rama actual.  Con --rebase, llamadas git-rebase  en lugar de git-merge. Tenga en cuenta que puede utilizar.  (directorio actual) como <repository> para extraer  desde el repositorio local - esto es útil cuando se combinan sucursales locales  en la rama actual. Git-pull  para git-fetch.

Si querrías que las historias se fusionaran, obtendrías si simplemente "quisieras el código", porque algunas de ellas ponen algunos artículos aquí.

161
15 нояб. Respuesta dada por Vinko Vrsalovic 15 de noviembre 2008-11-15 12:52 '08 a las 12:52 2008-11-15 12:52

Puede extraer del repositorio remoto, ver las diferencias y luego extraer o fusionar.

Este es un ejemplo de un repositorio remoto llamado origin y una rama llamada master , que rastrea el origin/master remoto origin/master rama origin/master :

 git checkout master git fetch git diff origin/master git rebase origin master 
147
21 марта '11 в 14:07 2011-03-21 14:07 La respuesta la da Antonio Bardazzi el 21 de marzo de 2011 a las 14:07 2011-03-21 14:07

La respuesta corta y simple es que git pull es simplemente git fetch seguido por git merge .

Es muy importante tener en cuenta que git pull se fusiona automáticamente, te guste o no . Esto, por supuesto, puede llevar a fusionar conflictos. Digamos que tu consola es origin y tu rama es master . Si es git diff origin/master antes de tirar, debe tener en cuenta los posibles conflictos de fusión y puede preparar su sucursal local en consecuencia.

Además de tirar y hacer clic, algunos flujos de trabajo incluyen git rebase , por ejemplo, este, que parafraseo de un artículo relacionado:

 git pull origin master git checkout foo-branch git rebase master git push origin foo-branch 

Si te encuentras en esta situación, puedes ser tentado por git pull --rebase . Si realmente no sabes lo que estás haciendo, te aconsejaría hacerlo. Esta es una advertencia de la página de man de git-pull , versión 2.3.5 :

Este es un modo de operación potencialmente peligroso. Él reescribe una historia que no augura nada bueno cuando ya ha publicado esta historia. No utilice este parámetro si no ha leído cuidadosamente git-rebase (1).

139
15 мая '11 в 23:53 2011-05-15 23:53 la respuesta la da jfmercer el 15 de mayo de 2011 a las 23:53 2011-05-15 23:53

2019

117
06 февр. la respuesta se da th3sly 06 feb. 2015-02-06 14:48 '15 a las 14:48 2015-02-06 14:48

Bueno , aquí hay información sobre git pull y git fetch , para que pueda comprender las diferencias reales ... en pocas palabras, fetch obtiene los datos más recientes, pero no cambia el código y no va a comunicarse con su código de sucursal local actual, pero saque el código con los cambios y fusionarlo en su sucursal local, siga leyendo para obtener información más detallada sobre cada uno:

git fetch

Descargará todos los enlaces y objetos y cualquier rama nueva a su repositorio local ...

Elija ramas y / o etiquetas (juntas, "refs") de uno o más repositorios, junto con los objetos necesarios para completar sus historias. Ramas de seguimiento remoto actualizadas (vea la descripción a continuación para conocer las formas de controlar este comportamiento).

De forma predeterminada, también se recupera cualquier etiqueta que apunte a historias extraídas; el efecto es extraer etiquetas que apuntan a las ramas en las que está interesado. Este comportamiento predeterminado se puede cambiar mediante las opciones --tags o --no-tags o configurando el mando a distancia..tagOpt. Al usar refspec, que extrae etiquetas de manera explícita, puede extraer etiquetas que no apuntan a las ramas en las que está interesado.

git fetch se puede recuperar desde un único repositorio con nombre o URL, o desde varios repositorios a la vez, si están disponibles, y hay consolas. escribir en el archivo de configuración. (Ver Git-config 1 ).

Si no se especifica ningún dispositivo remoto, se usa la fuente de inicio predeterminada, a menos que se configure una rama ascendente para la rama actual.

Los nombres de los enlaces que se seleccionan, junto con los nombres de los objetos a los que apuntan, se registran en.git / FETCH_HEAD. Esta información puede ser utilizada por scripts u otros comandos de git, como git-pull.


git pull

Se aplicarán los cambios de remoto a la rama actual en local ...

Incluye cambios desde un repositorio remoto a la rama actual. En el modo predeterminado, git pull es una abreviatura de git fetch, seguida de git merge FETCH_HEAD.

Más específicamente, git pull ejecuta git fetch con los parámetros dados y llama a git merge para combinar los encabezados de rama recibidos en la rama actual. Usando --rebase, ejecuta git rebase en lugar de git merge.

debe ser el nombre del repositorio remoto pasado a git-fetch 1 . puede llamar a una referencia remota arbitraria (por ejemplo, el nombre de la etiqueta) o incluso a una colección de enlaces con las correspondientes ramas de seguimiento remoto (por ejemplo, refs / heads /: refs / remotes / origin /), pero generalmente este es el nombre de la rama en el repositorio remoto.

Los valores predeterminados para y se leen de las configuraciones "remota" y "fusionada" para la rama actual, según lo establecido por git-branch --track.


También creo una imagen visual a continuación para mostrarte cómo funcionan juntos git fetch y git pull ...

2019

21 июня '17 в 12:48 2017-06-21 12:48 Alireza da la respuesta el 21 de junio de 2017 a las 12:48 2017-06-06 12:48

Bonus

Hablando de estiramiento y extracción en las respuestas anteriores, me gustaría compartir un truco interesante,

git pull --rebase

Este comando anterior es el comando más útil en mi vida de git, que ha ahorrado mucho tiempo.

Antes de enviar nuevas confirmaciones al servidor, intente este comando, se sincronizarán automáticamente los últimos cambios del servidor (usando fetch + merge) y su mensaje aparecerá al principio en el registro de git. No hay que preocuparse por tirar / fusionar las manos.

Encuentre información en: http://gitolite.com/git-pull--rebase

113
23 дек. La respuesta la da Sazzad Hissain Khan el 23 de diciembre. 2015-12-23 18:31 '15 a las 18:31 2015-12-23 18:31

Me gusta tener algún tipo de representación visual de la situación para entender estas cosas. Tal vez otros desarrolladores también quieran ver esto, así que aquí está mi adición. No estoy seguro de que todo esté correcto, así que por favor comente si encuentra algún error.

  LOCAL SYSTEM . ===================================================== ================= . ================= =================== ============= REMOTE REPOSITORY . REMOTE REPOSITORY LOCAL REPOSITORY WORKING COPY (ORIGIN) . (CACHED) for example, . mirror of the a github repo. . remote repo Can also be . multiple repo . . . FETCH *------------------>* Your local cache of the remote is updated with the origin (or multiple external sources, that is git distributed nature) . PULL *-------------------------------------------------------->* changes are merged directly into your local copy. when conflicts occur, you are asked for decisions. . COMMIT . *<---------------* When coming from, for example, subversion, you might think that a commit will update the origin. In git, a commit is only done to your local repo. . PUSH *<---------------------------------------* Synchronizes your changes back into the origin. 

Algunos de los principales beneficios de tener una consola de imagen de espejo son:

  • Rendimiento (desplazando todos los mensajes y confirmaciones sin intentar comprimirlo a través de la red)
  • Comentarios sobre el estado de su repositorio local (por ejemplo, uso Atlassian SourceTree, que me dará una bombilla que indica si iré hacia adelante o hacia atrás en comparación con la fuente. Actualice con GIT FETCH).
107
20 февр. La respuesta la da Justus Romijn el 20 de febrero. 2014-02-20 00:18 14 a las 0:18 2014-02-20 00:18

También luché con esto. De hecho, llegué aquí con la búsqueda de Google para exactamente la misma pregunta. Después de leer todas estas respuestas, finalmente dibujé una imagen en mi cabeza y decidí tratar con el estado de 2 repositorios y 1 caja de arena, y las acciones realizadas con el tiempo, observando su versión. Entonces, eso es lo que se me ocurrió. Por favor corrígeme si me equivoco.

Tres repositorios con una muestra:

 --------------------- ----------------------- ----------------------- - Remote Repo - - Remote Repo - - Remote Repo - - - - gets pushed - - - - @ R01 - - @ R02 - - @ R02 - --------------------- ----------------------- ----------------------- --------------------- ----------------------- ----------------------- - Local Repo - - Local Repo - - Local Repo - - pull - - - - fetch - - @ R01 - - @ R01 - - @ R02 - --------------------- ----------------------- ----------------------- --------------------- ----------------------- ----------------------- - Local Sandbox - - Local Sandbox - - Local Sandbox - - Checkout - - new work done - - - - @ R01 - - @ R01+ - - @R01+ - --------------------- ----------------------- ----------------------- 

Tres repositorios con una carga.

 --------------------- ----------------------- ----------------------- - Remote Repo - - Remote Repo - - Remote Repo - - - - gets pushed - - - - @ R01 - - @ R02 - - @ R02 - --------------------- ----------------------- ----------------------- --------------------- ----------------------- ----------------------- - Local Repo - - Local Repo - - Local Repo - - pull - - - - pull - - @ R01 - - @ R01 - - @ R02 - --------------------- ----------------------- ----------------------- --------------------- ----------------------- ----------------------- - Local Sandbox - - Local Sandbox - - Local Sandbox - - Checkout - - new work done - - merged with R02 - - @ R01 - - @ R01+ - - @R02+ - --------------------- ----------------------- ----------------------- 

Esto me ayudó a entender por qué el muestreo es muy importante.

95
17 июля '12 в 19:43 2012-07-17 19:43 la respuesta se da pn1 amigo 17 de julio de 2012 a las 7:43 pm 2012-07-17 19:43

La diferencia entre GIT Fetch y GIT Pull puede explicarse por el siguiente escenario: (Recordando que las imágenes hablan más que las palabras, proporcioné una representación gráfica)

Supongamos que está trabajando en un proyecto con miembros de su equipo. Por lo tanto, serán una de las divisiones principales del proyecto, y todos los participantes deben ramificarse en su propio repositorio local, y luego trabajar en esta rama local para cambiar / agregar módulos, y luego regresar a la rama principal.

Por lo tanto, el estado inicial de las dos ramas, cuando bifurque el proyecto principal en su repositorio local, será así: ( A , B y C son los módulos ya completados en el proyecto)

2019

ответ дан Aman Tiwari 07 февр. '17 в 17:15 2017-02-07 17:15