it-swarm-es.com

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

Nota del moderador: Dado que esta pregunta ya ha recibido sesenta y siete respuestas publicadas (algunas de ellas eliminadas), considere ya sea que esté o no contribuyendo con algo nuevo antes de publicar otro.

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

11205
pupeno

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

Puede hacer un git fetch en cualquier momento para actualizar sus sucursales 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 personas que ejecutan git fetch periódicamente en un trabajo cron en segundo plano (aunque no recomendaría hacerlo).

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

Documentación de Git: git pull

8962
Greg Hewgill
  • Cuando usas pull, Git intenta hacer tu trabajo automáticamente por ti. Es sensible al contexto , por lo que Git combinará cualquier confirmación extraída en la rama en la que está trabajando actualmente. pull fusiona automáticamente las confirmaciones sin permitirle revisarlas primero . Si no administra sus sucursales de manera cercana, puede tener conflictos frecuentes.

  • Cuando fetch, Git recopila cualquier confirmación de la rama objetivo que no existe en su rama actual y los almacena en su repositorio local . Sin embargo, no los combina 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 maestra, use merge.

1969
Mouna Cheikhna

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 cliente/servidor. Existe un único repositorio que es el servidor, y varios clientes pueden obtener el código del servidor, trabajar en él y luego enviarlo de nuevo al servidor. El supuesto es que el cliente siempre puede contactar al servidor cuando necesita realizar una operación.

Git fue diseñado para admitir un modelo más distribuido sin necesidad de un repositorio central (aunque puede usar uno si lo desea). Además, git fue diseñado para que el cliente y el "servidor" no tengan que estar en línea al mismo tiempo. Git fue diseñado para que las personas en un enlace no confiable pudieran intercambiar códigos a través del correo electrónico, incluso. Es posible trabajar completamente desconectado 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 y también un repositorio local adicional que refleja el estado del repositorio remoto. Al mantener una copia del repositorio remoto localmente, git puede descubrir los cambios necesarios incluso cuando no se puede acceder al repositorio remoto. Más tarde, cuando necesite enviar los cambios a otra persona, git puede transferirlos como un conjunto de cambios desde un punto en el tiempo conocido por el repositorio remoto.

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

  • git pulldice "llevar los cambios en el repositorio remoto a donde guardo mi propio código".

Normalmente,git pullhace esto haciendo ungit fetchpara 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.

Lo importante es tener en cuenta que a menudo hay al menos tres copias de un 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 en la que está editando y construyendo. La tercera copia es su copia local "en caché" de un repositorio remoto.

1104
MikeD

Aquí está la imagen de Oliver Steele de cómo todo encaja entre sí :

enter image description here

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

744
Contango

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

git fetch
git diff ...Origin
446
mepster

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, obtienes todo el repositorio a tu Host local. Esto significa que en ese momento tiene un puntero de Origen/Maestro a HEAD y un maestro que apunta a la misma HEAD.

cuando comienzas a trabajar y realizas confirmaciones, avanzas el puntero maestro a HEAD + tus confirmaciones. Pero el puntero Origen/maestro sigue apuntando a lo que era cuando clonaste.

Así que la diferencia será:

  • Si hace un git fetch, solo recuperará todos los cambios en el repositorio remoto ( GitHub ) y moverá el puntero del Origen/maestro a HEAD. Mientras tanto, su maestro de sucursal local seguirá apuntando a dónde tiene.
  • Si hace un git pull, básicamente se recuperará (como se explicó anteriormente), fusionará cualquier cambio nuevo en su rama maestra y moverá el puntero a HEAD.
351
Gerardo

A veces una representación visual ayuda.

 enter image description here

195
thedarkpassenger

Brevemente

git fetch es similar 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 baja de un control remoto y se fusiona instantáneamente.

Más

git clone clona un repo.

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

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

Esta entrada 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é que actualizaría esto para mostrar cómo lo usarías en la práctica. 

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

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

    git diff master Origin/master 
    
  3. Si estás contento con esas actualizaciones, entonces fusiona:

    git pull
    

Notas:

En el paso 2: para obtener más información sobre las diferencias entre los controles locales y remotos, consulte: ¿Cómo comparar una rama local de git con su rama remota?

En el paso 3: probablemente sea más preciso (por ejemplo, en un repositorio de cambio rápido) hacer un 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/

189
Snowcrash
 git-pull - Recupera y fusiona con otro repositorio o una sucursal local 
 SINOPSIS 
 
 git pull ... 
 DESCRIPCIÓN 
 
 Ejecuta git-fetch con los parámetros dados, y llama a git-merge para fusionar los 
 Cabezales recuperados en la rama actual. Con --rebase, se llama git-rebase 
 En lugar de git-merge. 
 
 Tenga en cuenta que puede usar. (directorio actual) como <repository> para extraer 
 del repositorio local, esto es útil cuando se combinan las sucursales locales 
 en la rama actual. 
 
 También tenga en cuenta las opciones para git-pull en sí mismas y la subyacente git-merge 
 deben darse antes de las opciones para git-fetch. 

Si querrías que las historias se fusionaran, obtendrías una respuesta si simplemente 'quieres el código', ya que alguna persona ha estado etiquetando algunos artículos por aquí.

164
Vinko Vrsalovic

Puede obtener desde un repositorio remoto, ver las diferencias y luego extraer o fusionar.

Este es un ejemplo para un repositorio remoto llamado Origin y una rama llamada master que sigue la rama remota Origin/master:

git checkout master                                                  
git fetch                                        
git diff Origin/master
git rebase Origin master
151
Antonio Bardazzi

La respuesta breve y sencilla es que git pull es simplemente git fetch seguido de git merge.

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

Además de jalar y empujar, algunos flujos de trabajo involucran 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 se encuentra en tal situación, puede verse tentado a git pull --rebase. A menos que realmente, realmente sepas lo que estás haciendo, aconsejaría no hacerlo. Esta advertencia proviene de la página man para git-pull, versión 2.3.5:

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

145
jfmercer

OK, aquí hay información sobre git pull y git fetch, para que puedas entender las diferencias reales ... en pocas palabras simples, fetch obtiene los datos más recientes, pero no el código cambia y no va. para jugar con su código de sucursal local actual, pero pull obtenga los cambios de código y fusione su sucursal local, siga leyendo para obtener más detalles sobre cada uno:

git fetch

Descargará todos los refs y objects y cualquier rama nueva a su Repositorio local ...

Obtenga ramas y/o etiquetas (colectivamente, "refs") de uno o más Otros repositorios, junto con los objetos necesarios para completar sus Historias. Las ramas de seguimiento remoto se actualizan (consulte la descripción A continuación para conocer las formas de controlar este comportamiento).

De forma predeterminada, cualquier etiqueta que apunte a las historias que se están recuperando también se recupera ; el efecto es recuperar las etiquetas que apuntan a las ramas que le interesan . Este comportamiento predeterminado se puede cambiar usando las opciones --tags o --no-tags o configurando remoto..tagOpt. Al usar un refspec que obtiene etiquetas de manera explícita, También puede obtener etiquetas que no apuntan a las ramas en las que está interesado .

git fetch puede obtenerse desde un solo repositorio con nombre o URL, o desde varios repositorios a la vez si se proporciona y hay un controles remotos. Entrada en el archivo de configuración. (Ver git-config 1 ).

Cuando no se especifica ningún control remoto, de manera predeterminada, se utilizará , A menos que haya una rama ascendente configurada para la rama Actual.

Los nombres de las referencias que se recuperan, junto con los nombres de objeto A los que apuntan, se escriben en .git/FETCH_HEAD. Esta información puede ser Utilizada por scripts u otros comandos de git, como git-pull.


git pull

Aplicará los cambios de remote a current branch en local ...

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

Más precisamente, git pull ejecuta git fetch con los parámetros dados y Llama a git merge para combinar las cabezas de rama recuperadas en la rama Actual. Con --rebase, ejecuta git rebase en lugar de git merge.

debe ser el nombre de un repositorio remoto tal como se pasa a git-fetch 1 . puede nombrar a una referencia remota arbitraria (por ejemplo, el nombre de una etiqueta) o incluso a una colección de referencias con las ramas de seguimiento remoto correspondientes (por ejemplo, refs/heads/: refs/remotes/Origin /), pero generalmente es el nombre de una rama en el repositorio remoto.

Los valores predeterminados para y se leen de la configuración "Remota" y "fusionar" para la rama actual según lo establecido por Git-branch --track.


También creo el visual a continuación para mostrarle cómo git fetch y git pull trabajan juntos ...

 git pull and git fetch

126
Alireza

enter image description here

Esta representación gráfica interactiva es muy útil para entender git: http://ndpsoftware.com/git-cheatsheet.html

git fetch simplemente "descarga" los cambios desde el control remoto a su repositorio local. git pull descarga los cambios y los combina en su rama actual. "En su modo predeterminado, git pull es una abreviatura de git fetch seguido de git merge FETCH_HEAD".

121
th3sly

Prima:

Al hablar de pull & fetch 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 ahorró mucho tiempo.

Antes de enviar sus nuevos confirmaciones al servidor, pruebe este comando, se sincronizarán automáticamente los últimos cambios del servidor (con fetch + merge) y colocará su confirmación en la parte superior del registro de git. No hay necesidad de preocuparse por la extracción/fusión manual.

Encuentre los detalles en: http://gitolite.com/git-pull--rebase

119

Me gusta tener una representación visual de la situación para comprender estas cosas. Tal vez otros desarrolladores también quieran verlo, así que aquí está mi adición. No estoy totalmente seguro de que todo sea correcto, así que 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's   .
                  .
                  .
FETCH  *------------------>*
Your local cache of the remote is updated with the Origin (or multiple
external sources, that is git's 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.

Algunas de las principales ventajas de tener un espejo del control remoto son:

  • Rendimiento (desplácese a través de todos los mensajes y confirmaciones sin intentar exprimirlo a través de la red)
  • Retroalimentación sobre el estado de su repositorio local (por ejemplo, uso SourceTree de Atlassian, que me dará una bombilla que indica si me comprometo por delante o por detrás en comparación con el origen. ).
109
Justus Romijn

He luchado con esto también. De hecho, llegué aquí con una búsqueda en google de exactamente la misma pregunta. Al leer todas estas respuestas, finalmente pinté una imagen en mi cabeza y decidí intentar ver esto en el estado de los 2 repositorios y 1 caja de arena y las acciones realizadas a lo largo del tiempo mientras observaba la versión de ellos. Así que aquí es lo que se me ocurrió. Por favor, corrígeme si me equivoco en cualquier lugar.

Los tres repos con un fetch:

---------------------     -----------------------     -----------------------
- 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+               -
---------------------     -----------------------     -----------------------

Los tres repos con un tirón.

---------------------     -----------------------     -----------------------
- 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é una búsqueda es bastante importante.

99
pn1 dude

La diferencia entre GIT Fetch y GIT Pull se puede explicar con el siguiente escenario: (¡Teniendo en cuenta que las imágenes hablan más que las palabras! He proporcionado una representación gráfica)

Tomemos un ejemplo de que está trabajando en un proyecto con los miembros de su equipo. Por lo tanto, habrá una rama principal del proyecto y todos los contribuyentes deben vincularlo a su propio repositorio local y luego trabajar en esta rama local para modificar/agregar módulos y luego volver a la rama principal.

Entonces, Estado inicial de las dos Ramas cuando bifurcaste el proyecto principal en tu repositorio local será así: (A, B y C son módulos ya completados del proyecto)

 enter image description here

Ahora, ha comenzado a trabajar en el nuevo módulo (suponga D) y cuando haya completado el módulo D, desea enviarlo a la rama principal. Pero mientras tanto, uno de sus compañeros de equipo ha desarrollado el nuevo Módulo E, F y modificada C.
Así que ahora, lo que sucedió es que su repositorio local no se encuentra detrás del progreso original del proyecto y, por lo tanto, empujar sus cambios a la rama principal puede generar conflictos y hacer que su Módulo D no funcione correctamente.

 enter image description here

Para evitar tales problemas y trabajar en paralelo con el progreso original del proyecto, hay dos formas:

1. Git Fetch- Esto descargará todos los cambios que se hayan realizado en el proyecto Origen/rama principal que no están presentes en su sucursal local. Y esperará a que el comando Git Merge aplique los cambios que se han recuperado en su Repositorio o sucursal.

 enter image description here

Así que ahora puede monitorear cuidadosamente los archivos antes de fusionarlos con su repositorio. Y también puede modificar D si es necesario debido a Modified C.

 enter image description here

2. Git Pull- Esto actualizará tu sucursal local con el Origen/rama principal, es decir, en realidad lo que hace es una combinación de Git Fetch y Git se fusionan una tras otra. Pero esto puede causar Se producirán conflictos, por lo que se recomienda usar Git Pull con una copia limpia.

 enter image description here

89
Aman Tiwari

Simplemente decimos:

git pull == git fetch + git merge

Si ejecuta git pull, no necesita combinar los datos con el local. Si ejecuta git fetch, significa que debe ejecutar git merge para obtener el código más reciente para su máquina local. De lo contrario, el código de máquina local no se cambiaría sin la combinación. 

Por lo tanto, en Git Gui, cuando se realiza la búsqueda, hay que fusionar los datos. Fetch en sí no hará los cambios de código en su local. Puede verificar que cuando actualice el código, busque Una vez que se encuentre y vea; El código no cambiará. Luego te fusionas ... Verás el código modificado.

82
Selvamani

git fetch baja el código del servidor remoto a sus sucursales de seguimiento en su repositorio local. Si su control remoto se llama Origin (el valor predeterminado), estas sucursales estarán dentro de Origin/, por ejemplo Origin/master, Origin/mybranch-123, etc. Estas no son sus sucursales actuales, son local copias de esas sucursales desde el servidor.

git pull hace un git fetch pero luego también combina el código de la rama de seguimiento en su versión local actual de esa rama. Si aún no está listo para los cambios, solo git fetch primero.

80
Michael Durrant

git fetch recuperará sucursales remotas para que pueda git diff o git merge con la rama actual. git pull ejecutará fetch en el archivo remoto rastreado por la rama actual y luego fusionará el resultado. Puede usar git fetch para ver si hay actualizaciones para la sucursal remota sin que sea necesario combinarlas con su sucursal local.

75
ntanase

Git Fetch

Usted descarga los cambios a su sucursal local desde Origin hasta fetch. Fetch solicita el repositorio remoto para todas las confirmaciones que otros hayan hecho pero no tiene en su repositorio local. Fetch descarga estos compromisos y los agrega al repositorio local.

Git Merge

Puede aplicar los cambios descargados a través de búsqueda utilizando el comando de combinación. Combinar tomará las confirmaciones recuperadas de la búsqueda e intentará agregarlas a su sucursal local. La fusión mantendrá el historial de confirmación de sus cambios locales para que cuando comparta su sucursal con Push, Git sepa cómo otros pueden combinar sus cambios.

Git Pull

La búsqueda y la fusión se ejecutan juntas con la suficiente frecuencia como para crear un comando que combina las dos, extracción. Pull realiza una búsqueda y luego una combinación para agregar las confirmaciones descargadas en su sucursal local.

71
Pinkesh Sharma

La única diferencia entre git pull y git fetch es que:

git pull saca de una rama remota y la fusiona.

git fetch solo recupera desde la rama remota pero no se fusiona

es decir, git pull = git fetch + git merge ...

50

Git permite que los compromisos cronológicamente más antiguos se apliquen después de los nuevos. Debido a esto, el acto de transferir los compromisos entre los repositorios se divide en dos pasos:

  1. Copiando nuevas confirmaciones desde una rama remota a una copia de esta rama remota dentro del repositorio local. 

    (Repo para repo operación) [email protected] >> remote/Origin/[email protected]

  2. Integrando nuevos compromisos a la sucursal local.

    (Operación dentro del repositorio) remote/Origin/[email protected] >> [email protected]

Hay dos formas de hacer el paso 2. Puedes:

  1. Bifurque la rama local después del último ancestro común y agregue nuevos confirmaciones paralelas a las confirmaciones que son exclusivas del repositorio local, finalizadas mediante la combinación de confirmaciones, cerrando la horquilla. 
  2. Inserte nuevas confirmaciones después del último ancestro común y vuelva a aplicar las confirmaciones únicas al repositorio local.

En la terminología de git, el paso 1 es git fetch, el paso 2 es git merge o git rebase

git pull es git fetch y git merge

44
Pawel Furmaniak

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

Para entender esto, primero debe comprender que su git local no solo mantiene su repositorio local, sino que también mantiene una copia local del repositorio remoto.

git fetch actualiza su copia local del repositorio remoto. Por ejemplo, si su repositorio remoto es GitHub, es posible que desee obtener todos los cambios realizados en el repositorio remoto en su copia local del repositorio remoto. Esto le permitirá realizar operaciones como comparar o fusionar.

Por otro lado, git pull reducirá los cambios en el repositorio remoto donde guardará su propio código. Normalmente, git pull hará primero 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 en su copia de trabajo. 

36
Donal

Git obtiene la rama de la última versión del remoto al local usando dos comandos: 

  1. git fetch: Git obtendrá la última versión de remoto a local, pero no se fusionará automáticamente. git fetch Origin mastergit log -p master..Origin/mastergit merge Origin/master

     Los comandos anteriores significan que descargan la última versión de la rama principal desde el Origen desde el remoto hasta la rama principal del Origen. Y luego compara la rama maestra local y la rama maestra de origen. Finalmente, fusionar. 

  2. git pull: Git obtendrá la última versión del control remoto y se fusionará con el local.

    git pull Origin master

     El comando anterior es equivalente a git fetch y git merge. En la práctica, git fetch puede ser más seguro porque antes de la fusión podemos ver los cambios y decidir si se fusionan.

35
Marcus Thornton

git pull == (git fetch + git merge) 

git fetch no cambia a las sucursales locales.

Si ya tiene un repositorio local con una configuración remota para el proyecto deseado, puede tomar todas las ramas y etiquetas para el control remoto existente utilizando git fetch. ... Fetch no realiza ningún cambio en las sucursales locales, por lo que deberá fusionar una sucursal remota con una sucursal local emparejada para incorporar los cambios de recuperación recientes. desde github

33
Iggy

En realidad, Git mantiene una copia de su propio código y El repositorio remoto.

El comando git fetch hace que su copia local esté actualizada al obtener datos del repositorio remoto. La razón por la que necesitamos esto es porque alguien más podría haber realizado algunos cambios en el código y usted desea mantenerse actualizado. 

El comando git pull lleva los cambios en el repositorio remoto a donde guarda su propio código. Normalmente, git pull hace esto haciendo primero un ‘git fetch’ para actualizar la copia local del repositorio remoto, y luego combina los cambios en su propio repositorio de código y posiblemente en su copia de trabajo.

32
Pokemon

Tratando de ser claro y sencillo.

El comando git pull es en realidad un shortcut para git fetch seguido del git merge o el git rebase dependiendo de su configuración. Puede configurar su repositorio de Git para que git pull sea una búsqueda seguida de una rebase.

31
montells

Una simple representación gráfica para principiantes,

 enter image description here

aquí,

git pull  

buscará el código del repositorio y lo reajustará con su local ... en git pull existe la posibilidad de que se creen nuevos confirmaciones.

pero en , 

git fetch 

obtendremos el código del repositorio y necesitamos volver a configurarlo manualmente usando git rebase

por ejemplo: voy a buscar desde el servidor maestro y lo reagrupo en mi maestro local.

1) git pull (rebase se hará automáticamente):

git pull Origin master

aquí Origen es su repositorio remoto maestro es su rama

2) git fetch (hay que reajustar manualmente):

git fetch Origin master

recuperará los cambios del servidor desde el origen. y estará en tu local hasta que lo modifiques por tu cuenta. Necesitamos arreglar conflictos manualmente revisando los códigos.

git rebase Origin/master

esto volverá a cambiar el código en local. antes de eso asegúrate de estar en la rama derecha.

30
git pull = git fetch + git merge 
29
Saqib R.

De Pro Git § 2.5 Conceptos básicos de Git - Trabajar con controles remotos: Recuperar y extraer de sus controles remotos :

Es importante tener en cuenta que el comando fetch arrastra los datos a su repositorio local, no Los fusiona automáticamente con ninguno de sus trabajos ni modifica en qué está trabajando Actualmente. Debe combinarlo manualmente en su trabajo Cuando esté listo.

Si tiene una sucursal configurada para rastrear una sucursal remota, puede usar el comando git pull para buscar automáticamente y luego combinar una sucursal remota En su sucursal actual. Esto puede ser más fácil o más cómodo para usted; y de manera predeterminada, el comando git clone configura automáticamente su sucursal maestra local para rastrear la rama maestra remota en el servidor que clonó (asumiendo que el control remoto tiene una rama maestra ) . La ejecución de git pull generalmente obtiene datos del servidor Desde el que se clonó originalmente e intenta automáticamente fusionarlos En el código en el que está trabajando actualmente.

28
Zhenxiao Hao

git pull  

Realiza dos funciones utilizando un solo comando.

Obtiene todos los cambios que se hicieron en la sucursal remota y luego combina esos cambios en su sucursal local. También puede modificar el comportamiento de extracción pasando --rebase. La diferencia entre fusionar y rebase se puede leer aquí

git fetch

Git fetch hace solo la mitad del trabajo de git pull. Simplemente trae los cambios remotos a su repositorio local pero no los aplica a sus sucursales. Debe aplicar esos cambios explícitamente. Esto puede hacerse de la siguiente manera:

git fetch
git rebase Origin/master
22
Animesh Sharma

Hay que tener en cuenta la naturaleza del git. Tiene controles remotos y sus sucursales locales (no necesariamente lo mismo). En comparación con otros sistemas de control de fuente, esto puede ser un poco desconcertante. 

Por lo general, cuando se registra un control remoto, se crea una copia local que rastrea el control remoto. 

git fetch funcionará con la rama remota y actualizará su información. 

En realidad, es el caso si otras SWE están trabajando en la misma rama, y ​​raramente en el caso de un desarrollador pequeño, una rama, escenarios de un proyecto.

Su trabajo en la sucursal local sigue intacto. Para llevar los cambios a su sucursal local, debe fusionar/reajustar los cambios desde la sucursal remota.

git pull hace exactamente estos dos pasos (es decir, rebasar a rebase en lugar de fusionar)

Si su historial local y el historial remoto tienen conflictos, se verá obligado a realizar la fusión durante un git Push para publicar sus cambios.

Por lo tanto, realmente depende de la naturaleza de su entorno de trabajo y la experiencia de qué usar.

22
g24l

Desde git cheat sheet

git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD
20
Nan Xiao

De lo que entendí, 

Git pull - Despliega un control remoto específico (especificado por el usuario) y lo fusionará instantáneamente en una rama en la que estamos actualmente. Es básicamente una mezcla de comandos Fetch y Merge.

Git Fetch - Es igual que Pull, pero no hará ninguna fusión. Así que puedes monitorear cuidadosamente los archivos antes de fusionarlos. 

Esta URL debe ser de ayuda para una mayor comprensión: La diferencia entre git pull, git fetch y git clone (y git rebase).

17
Pragyaditya Das

En términos cortos y sencillos:

git fetch: mira si hay cosas nuevas.

git pull: Toma las cosas nuevas y ponlas sobre tus cosas. 

8
miva2

Creo que la mayoría de las respuestas respondieron bastante bien a la diferencia. Me gustaría hacer hincapié en cuándo usar que en su lugar.

 Enter image description here

Fetch puede ser útil cuando necesita obtener la actualización de otros desarrolladores, pero desea continuar sin trabas en su trabajo. Las personas que a menudo desean desconectarse y trabajar usan fetch para obtener la última actualización hasta que él/ella estuvo en línea. Más tarde, cuando él/ella se siente cómodo con sus cambios, combina los de la sucursal con su área de trabajo.

Mientras que las personas que trabajan en línea y están muy seguras de sus cambios y desean obtener el último código y merge de inmediato, usan pull. Rara vez utilizo fetch porque para verificar las últimas actualizaciones, las verifico a través del sitio web de GitHub y siempre trabajo sin conexión. Como mencioné, es posible que tenga uso para el escenario anterior.

5
ishandutta2007

Git Fetch

Le ayuda a conocer las últimas actualizaciones de un git repository. Digamos que trabaja en un equipo usando GitFlow, donde el equipo trabaja en múltiples branches (características). Con git fetch --allcommand puede conocer todas las novedades de branches dentro de repository.

La mayoría de git fetch se usa con git reset. Por ejemplo, desea revertir todos sus cambios locales al estado actual del repositorio.

git fetch --all // get known about latest updates
git reset --hard Origin/[branch] // revert to current branch state

Git pull

Este comando actualiza su branch con el actual repositorybranch estado. Continuemos con GitFlow. La característica múltiple branches era merged a develop rama y cuando quiera desarrollar nuevas características para el proyecto, debe ir al desarrollo branch y hacer un git pull para obtener el estado actual de developbranch

Documentación para GitFlow https://Gist.github.com/peterdeweese/4251497

3
Andrei Todorut

Git fetch sincroniza el catálogo del repositorio remoto con su local. No fusionará los cambios de archivo/código de remoto a su sucursal local.

Git pull descarga los cambios relacionados con su sucursal local actual y luego la fusiona.

1
Arnel Lenteria

De este impresionante Attlassian tutorial: 

El comando git fetch descarga confirmaciones, archivos y referencias de un repositorio remoto a su repositorio local. 

Fetching es lo que haces cuando quieres ver en lo que todos else ha estado trabajando. Es similar a svn update porque le permite ver cómo ha progresado el historial central, pero no lo obliga a fusionar los cambios en su repositorio. Git aísla el contenido obtenido de un contenido local existente , tiene absolutamente ningún efecto en su trabajo de desarrollo local . El contenido extraído debe comprobarse explícitamente mediante el comando git checkout. Esto hace que la búsqueda sea una forma segura de revisar los compromisos antes de integrarlos en su repositorio local.

Al descargar contenido de un repositorio remoto, los comandos git pull y git fetch están disponibles para realizar la tarea. Puede considerar git fetch la versión 'segura' de los dos comandos. Descargará el contenido remoto pero no actualizará el estado de trabajo de su repo local, dejando intacto su trabajo actual. git pull es la alternativa más agresiva, descargará el contenido remoto para la rama local activa y ejecutará inmediatamente git merge para crear un compromiso de combinación para el nuevo contenido remoto. Si tiene cambios pendientes en curso, esto causará conflictos y dará inicio al flujo de resolución de conflictos de combinación.


Con git pull:

  • No consigues ningún aislamiento. 
  • Afecta en su desarrollo local.
  • No necesita ser comprobado explícitamente. Porque implícitamente hace un git merge.
  • Básicamente NO es seguro. Es agresivo.
  • A diferencia de git fetch, donde solo afecta a .git/refs/remotes, git pull también afectará a .git/refs/remotes y .git/refs/heads/.

Hmmm ... así que si no estoy actualizando la copia de trabajo con git fetch, ¿dónde estoy haciendo cambios? ¿Dónde git fetch almacena los nuevos compromisos?

Gran pregunta Lo pone en algún lugar aislado de su copia de trabajo. Pero otra vez donde? Vamos a averiguar.

En el directorio de su proyecto (es decir, donde hace sus comandos git) haga: 

  1. ls. Esto mostrará los archivos y directorios. Nada bueno, lo sé.

  2. Ahora haz ls -a. Esto mostrará archivos de puntos es decir, archivos que comienzan con . Luego podrá ver un directorio llamado: .git

  3. Hacer cd .git. Esto obviamente va a cambiar su directorio. 
  4. Ahora viene la parte divertida; hacer ls. Verás una lista de directorios. Estamos buscando refs. Hacer cd refs.
  5. Es interesante ver qué hay dentro de todos los directorios, pero concentrémonos en dos de ellos. heads y remotes. Use cd para verificar dentro de ellos también. 
  6. CUALQUIER git fetch que haga actualizará los elementos en el directorio /.git/refs/remotes. No actualizará nada en el directorio /.git/refs/heads.
  7. CUALQUIER git pull primero hará git fetch, actualizará los elementos en el directorio /.git/refs/remotes, luego se fusionará con su local y luego cambiará la cabecera dentro del directorio /.git/refs/heads

También se puede encontrar una muy buena respuesta relacionada ¿Dónde se ubica 'git fetch' en sí mismo?

También busque "Notación de barra" en Convenciones de nomenclatura de sucursales de Git post.

1
Honey