remote origin example ejemplo git git-pull git-fetch

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



git pull origin branch (30)

¿Cuál es la diferencia entre git pully git fetch?

Para comprender 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 fetchactualiza su copia local del repositorio remoto. Por ejemplo, si su repositorio remoto es GitHub, es posible que desee buscar los cambios realizados en el repositorio remoto en su copia local del repositorio remoto. Esto le permitirá realizar operaciones como comparar o fusionar.

git pullpor otro lado, reducirá los cambios en el repositorio remoto donde guardará su propio código. Normalmente, git pullse hará una git fetchprimera actualización de la copia local del repositorio remoto, y luego se fusionarán los cambios en su propio repositorio de código y posiblemente en su copia de trabajo.

Nota para el moderador: Dado que esta pregunta ya tiene sesenta y siete respuestas publicadas (algunas de ellas eliminadas), considere si está aportando algo nuevo antes de publicar otra.

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

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 nuevas 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 detalles en: http://gitolite.com/git-pull--rebase

A veces una representación visual ayuda.

En los términos más simples, git pull realiza una git fetch seguida de una git merge .

Puede realizar una git fetch en cualquier momento para actualizar sus sucursales de seguimiento remoto en refs/remotes/<remote>/ .

Esta operación nunca cambia ninguna de sus propias 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 Git: Git Pull

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 ponerse en contacto con el 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 ciertamente 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 puedan intercambiar códigos por 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 fetch es el comando que dice "actualizar mi copia local del repositorio remoto".

  • git pull dice "llevar los cambios en el repositorio remoto a 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 fusionando los cambios en su propio repositorio de código y posiblemente en su copia de trabajo.

Lo que debe tener en cuenta 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 donde está editando y construyendo. La tercera copia es su copia local "en caché" de un repositorio remoto.

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

Es muy importante tener en cuenta que git pull se fusionará automáticamente, te guste o no . Esto podría, por supuesto, dar lugar a conflictos de fusión. Digamos que tu control remoto es origin y tu 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 tirar y empujar, algunos flujos de trabajo incluyen 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 de man de git-pull , versión 2.3.5 :

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

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 haces confirmaciones, avanza el puntero maestro a HEAD + tus confirmaciones. Pero el puntero de origen / maestro sigue apuntando a lo que era cuando clonaste.

Así que la diferencia será:

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

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 por todas las confirmaciones y mensajes sin intentar exprimirlo a través de la red)
  • Comentarios sobre el estado de su repositorio local (por ejemplo, uso el SourceTree de Atlassian, que me dará un indicador que indica si estoy comprometido adelante o atrás en comparación con el origen. Esta información se puede actualizar con un GET FETCH)

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 rastrea el origin/master rama remota:

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

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

git fetch git diff ...origin

git fetchbaja el código del servidor remoto a sus sucursales de seguimiento en su repositorio local. Si el mando a distancia se llama origin(el valor predeterminado), entonces estas ramas estarán dentro de origin/, por ejemplo origin/master, origin/mybranch-123,, etc. Estos no son sus ramas actuales, que son locales copias de esas ramas del servidor.

git pullhace un, git fetchpero 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ás listo para los cambios, solo git fetchprimero.

git fetchrecuperará ramas remotas para que pueda git diffo git mergeellos con la rama actual. git pullejecutará fetch en el archivo remoto rastreado por la rama actual y luego fusionará el resultado. Puede usarlo git fetchpara ver si hay actualizaciones en la sucursal remota sin que sea necesario combinarlas con su sucursal local.

Bien , 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 meterse con su código de sucursal local actual , pero 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 objetos y cualquier rama nueva a su Repositorio local ...

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

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

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

Cuando no se especifica ningún control remoto, de forma predeterminada se usará el control remoto de origen, 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 los objetos 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

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

Incorpora cambios desde un repositorio remoto en 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 una referencia remota arbitraria (por ejemplo, el nombre de una etiqueta) o incluso una colección de referencias con las correspondientes ramas de seguimiento remoto (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 desde la configuración "remota" y "fusionar" para la rama actual tal como lo establece git-branch --track.

También creo la imagen a continuación para mostrarte cómo git fetch y git pull trabajan juntos ...

1

Brevemente

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

git pull tira de un control remoto y se fusiona instantáneamente.

Más

git clone clones a repo.

git rebase guarda las cosas de su rama actual que no se encuentran en la rama ascendente en un área temporal. Su rama es ahora la misma que antes de comenzar sus cambios. Por lo tanto, git pull -rebase reducirá los cambios remotos, rebobinará su sucursal local, volverá a reproducir los cambios en la parte superior de su rama 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 utilizarí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á satisfecho con esas actualizaciones, entonces fusione:

    git pull

Notas:

En el paso 2: Para obtener más información sobre las diferencias entre los controles 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 cambio rápido) hacer un git rebase origin aquí. Ver @Justin Ohms comentar en otra respuesta.

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

Git Fetch

Usted descarga los cambios a su sucursal local desde el origen hasta la recuperación. 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 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.

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

El comando git fetchhace 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 pulllleva los cambios en el repositorio remoto a donde guarda su propio código. Normalmente, git pullhace esto haciendo primero una ''búsqueda de git'' 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.

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 master git log -p master..origin/master git merge origin/master

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

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

    git pull origin master

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

Simplemente decimos:

git pull == git fetch + git merge

Si ejecuta git pull, no necesita combinar los datos a local. Si ejecuta git fetch, significa que debe ejecutar git mergepara obtener el último código 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 realiza la búsqueda, debe combinar los datos. Fetch en sí no hará que los cambios de código en su local. Puede verificar que cuando actualice el código extraiga una vez que busque y vea; El código no cambiará. Luego te fusionas ... Verás el código cambiado.

Tratando de ser claro y sencillo.

El comando git pull es en realidad un comando shortcutpara git fetch seguido por el comando git merge o git rebase dependiendo de su configuración. Puede configurar su repositorio Git para que git pull sea ​​una recuperación seguida de una rebase.

Una representación gráfica simple para principiantes,

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 volverlo a preparar 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í el origen es tu maestro de repositorio remoto es tu 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.

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 recién capturados. de github

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 seguida de git merge FETCH_HEAD ".

Git permite que los compromisos cronológicamente más antiguos se apliquen después de los nuevos. Debido a esto, el acto de transferir confirmaciones entre 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 a repo operación) master@remote >> remote/origin/master@local

  2. Integrando nuevos compromisos a la sucursal local.

    (Operación dentro del repositorio) remote/origin/master@local >> master@local

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 gitterminología, paso 1 es git fetch, paso 2 es git mergeogit rebase

git pulles git fetchygit merge

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.

La única diferencia entre git pully git fetches que:

git pull tira de una rama remota y la fusiona.

git fetch solo obtiene de la rama remota pero no se fusiona

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

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 pictórica)

Tomemos un ejemplo de que está trabajando en un proyecto con los miembros de su equipo. Por lo tanto, serán 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 enviarlos a la rama principal.

Así, estado inicial de las dos ramas bifurcadas cuando el principal proyecto en su repositorio local será como esto: ( A, By Cson módulos ya terminados del proyecto)

Ahora, que ha empezado a trabajar en el nuevo módulo (supongamos D) y cuando haya completado el Dmódulo que desea empujar a la rama principal, pero mientras tanto lo que pasa es que uno de sus compañeros de equipo ha desarrollado un nuevo módulo E, Fy modificado C.
Así que ahora, lo que sucedió es que su repositorio local carece del progreso original del proyecto y, por lo tanto, empujar sus cambios a la rama principal puede generar conflictos y causar que su Módulo no Dfuncione correctamente.

Para evitar tales problemas y para 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 de la sucursal de origen / 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.

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

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 conflictos, por lo que se recomienda usar Git Pull con una copia limpia.

git-pull - Fetch from and merge with another repository or a local branch SYNOPSIS git pull … DESCRIPTION Runs git-fetch with the given parameters, and calls git-merge to merge the retrieved head(s) into the current branch. With --rebase, calls git-rebase instead of git-merge. Note that you can use . (current directory) as the <repository> to pull from the local repository — this is useful when merging local branches into the current branch. Also note that options meant for git-pull itself and underlying git-merge must be given before the options meant for 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í.

git pull = git fetch + git merge

  • Cuando usas pull , Git intenta hacer automáticamente tu trabajo por ti. Es sensible al contexto , por lo que Git combinará cualquier compromiso extraído en la rama en la que está trabajando actualmente. pull combina automáticamente los compromisos sin permitirle revisarlos primero . Si no administra sus sucursales de manera cercana, puede tener conflictos frecuentes.

  • Cuando fetch , Git recopila cualquier confirmación de la rama de destino 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 .