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


Nota del moderador: Dado que esta pregunta ya ha tenido sesenta y cuatro respuestas publicado en él, considere si usted es o no aportando algo nuevo antes de publicar otro.

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


10125
2017-11-15 09:51


origen


Respuestas:


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

Puedes hacer un git fetch en cualquier momento para actualizar sus ramas de seguimiento remoto en refs/remotes/<remote>/.

Esta operación nunca cambia ninguna de sus sucursales locales bajo refs/heads, y es seguro hacerlo sin cambiar su copia de trabajo. Incluso he oído hablar de gente corriendo git fetch periódicamente en un trabajo de cron en el fondo (aunque no recomendaría hacer esto).

UN git pull es lo que haría para actualizar una sucursal local con su versión remota, al tiempo que actualiza sus otras sucursales de seguimiento remoto.

Documentación de Git: git pull


8455
2017-11-15 09:52



  • Cuando usas pull, Git intenta hacer tu trabajo automáticamente por ti. Es sensible al contexto, por lo que Git fusionará cualquier commit tirado en la rama en la que estás trabajando actualmente. pull  fusiona automáticamente las confirmaciones sin permitir que las revise primero. Si no administra sus ramas de cerca, puede encontrarse con conflictos frecuentes.

  • Cuando tú fetch, Git reúne cualquier confirmación de la rama de destino que no existe en tu rama actual y los almacena en su repositorio local. Sin embargo, no los fusiona con su rama actual. Esto es particularmente útil si necesita mantener su repositorio actualizado, pero está trabajando en algo que podría romperse si actualiza sus archivos. Para integrar las confirmaciones en su rama principal, use merge.


1849
2017-08-18 08:53



Es importante contrastar la filosofía de diseño de git con la filosofía de una herramienta de control de fuente más tradicional como SVN.

Subversion fue diseñado y construido con un modelo de cliente / servidor. Hay un único repositorio que es el servidor, y varios clientes pueden obtener el código del servidor, trabajar en él y luego volver a enviarlo al servidor. La suposición es que el cliente siempre puede contactar al servidor cuando necesita realizar una operación.

Git fue diseñado para soportar un modelo más distribuido sin necesidad de un repositorio central (aunque puedes usar uno si quieres). También git fue diseñado para que el cliente y el "servidor" no necesiten estar en línea al mismo tiempo. Git fue diseñado para que las personas en un enlace poco confiable puedan intercambiar código por correo electrónico, incluso. Es posible trabajar completamente desconectado y grabar un CD para intercambiar código a través de git.

Para soportar este modelo, git mantiene un repositorio local con su código y también un repositorio local adicional que refleja el estado del repositorio remoto. Al mantener localmente una copia del repositorio remoto, git puede descubrir los cambios necesarios incluso cuando el repositorio remoto no es accesible. Más tarde, cuando necesite enviar los cambios a otra persona, git puede transferirlos como un conjunto de cambios desde un punto conocido en el repositorio remoto.

  • git fetches el comando que dice "actualizar mi copia local del repositorio remoto".

  • git pull dice "traer los cambios en el repositorio remoto donde guardo mi propio código".

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

El llevar es tener en cuenta que a menudo hay al menos tres copias de un proyecto en su estación de trabajo. Una copia es tu propio repositorio con tu propio historial de compromisos. La segunda copia es tu copia de trabajo donde estás editando y construyendo. La tercera copia es su copia local "en caché" de un repositorio remoto.


1007
2018-03-31 18:43



Aquí está La imagen de Oliver Steele de cómo todo encaja:

enter image description here

Si hay suficiente interés, supongo que podría actualizar la imagen para agregar git clone y git merge...


660
2018-06-09 13:30



Un caso de uso de git fetch es que lo siguiente le dirá cualquier cambio en la rama remota desde su última extracción ... para que pueda verificar antes de realizar una extracción real, lo que podría cambiar los archivos en su rama actual y copia de trabajo.

git fetch
git diff ...origin

427
2018-05-07 19:23



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

Cuando clonas un repositorio, traes todo el repositorio a tu host local. Esto significa que en ese momento tiene un puntero de origen / maestro para HEAD y maestro apuntando a lo mismo HEAD.

cuando empiezas a trabajar y haces commits avanzas el puntero principal a HEAD + tus compromisos. Pero el puntero de origen / maestro aún apunta a lo que era cuando clonaste.

Entonces la diferencia será:

  • Si haces una git fetch simplemente obtendrá todos los cambios en el repositorio remoto (GitHub) y mueva el puntero de origen / maestro a HEAD. Mientras tanto, su jefe de sucursal local seguirá señalando hacia dónde se dirige.
  • Si haces una git pull, básicamente buscará (como se explicó anteriormente) y combinará cualquier cambio nuevo a su rama principal y moverá el puntero a HEAD.

341
2018-05-11 18:37



Algunas veces una representación visual ayuda.

enter image description here


179
2018-01-25 17:28



Brevemente

git fetch es parecido a pull pero no se fusiona. es decir, obtiene actualizaciones remotas (refs y objects) pero su local permanece igual (es decir origin/master se actualiza pero master Se mantiene igual) .

git pull se detiene desde un control remoto y se fusiona al instante.

Más

git clone clona un repositorio.

git rebase guarda cosas de su rama actual que no está en la rama ascendente a un área temporal. Su sucursal ahora es la misma que antes de comenzar sus cambios. Asi que, git pull -rebase desplegará los cambios remotos, rebobinará su sucursal local, reproducirá los cambios en la parte superior de su bifurcación actual uno por uno hasta que esté actualizado.

También, git branch -a le mostrará exactamente lo que sucede con todas sus sucursales: local y remota.

Esta publicación de blog fue útil:

La diferencia entre git pull, git fetch y git clone (y git rebase) - Mike Pearce

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

====

ACTUALIZAR

Pensé en actualizar esto para mostrar cómo usarías esto en la práctica.

  1. Actualice su repositorio local desde el control remoto (pero no se fusione):

    git fetch

  2. Después de descargar las actualizaciones, veamos las diferencias:

    git diff master origin / master

  3. Si está contento con esas actualizaciones, entonces fusione:

    git pull

Notas:

En el paso 2: para obtener más información sobre diferencias entre locales y remotos, consulte: comparar la rama local de git con la rama remota?

En el paso 3: probablemente sea más preciso (por ejemplo, en un repositorio de cambios rápidos) hacer una git rebase origin aquí. Ver comentario de @Justin Ohms en otra respuesta.

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


165
2018-04-13 17:31



git-pull - Obtener y fusionarse con otro repositorio o una rama local
SINOPSIS

git pull ...
DESCRIPCIÓN

Ejecuta git-fetch con los parámetros dados, y llama a git-merge para fusionar el
recuperó cabeza (s) en la rama actual. Con --rebase, llamadas git-rebase
en lugar de git-merge

Tenga en cuenta que puede usar. (directorio actual) como el <repositorio> para tirar
del repositorio local: esto es útil cuando se fusionan sucursales locales
en la rama actual.

También tenga en cuenta que las opciones pensadas para git-pull en sí y subyacente git-merge
debe darse antes de las opciones para git-fetch.

Podrías tirar si quieres que las historias se fusionen, lo buscarías si solo 'quieres el códec' ya que alguna persona ha estado etiquetando algunos artículos aquí.


155
2017-11-15 09:52



Puede buscar desde un repositorio remoto, ver las diferencias y luego tirar o fusionar.

Este es un ejemplo de un repositorio remoto llamado origin y una rama llamada master rastreando la rama remota origin/master:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

143
2018-03-21 11:07



La respuesta corta y fácil es que git pull es simple git fetch seguido por git merge.

Es muy importante tener en cuenta que git pull será fusionar automáticamente si te gusta o no. Esto podría, por supuesto, resultar en conflictos de fusión. Digamos que su control remoto es origin y tu rama es master. Si tu git diff origin/master antes de tirar, debe tener alguna idea de los posibles conflictos de fusión y podría preparar su sucursal local en consecuencia.

Además de tirar y empujar, algunos flujos de trabajo involucrar git rebase, como este, que parafraseo del artículo vinculado:

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

Si te encuentras en tal situación, puedes sentirte tentado a git pull --rebase. A menos que realmente, realmente sepas lo que estás haciendo, te aconsejaría que no lo hicieras. Esta advertencia es de man página para git-pull, versión 2.3.5:

Este es un modo de operación potencialmente peligroso. Reescribe   historia, que no es un buen augurio cuando publicó ese historial   ya. No use esta opción a menos que haya leído git-rebase (1)   cuidadosamente.


132
2018-05-15 20:53