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

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

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

Puede hacer una git fetch en cualquier momento para actualizar sus twigs de rastreo 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 copy 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 hacer esto).

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

Documentación de Git: git pull

  • Cuando usa pull , Git intenta hacer su trabajo automáticamente por usted. Es sensible al context , por lo que Git fusionará las confirmaciones extraídas en la sucursal en la que está trabajando actualmente. pull combina automáticamente las confirmaciones sin permitirle revisarlas primero . Si no administra sus twigs de cerca, puede encontrarse con conflictos frecuentes.

  • Cuando fetch , Git reúne las confirmaciones de la sucursal objective que no existen en tu sucursal actual y las almacena en tu depósito local . Sin embargo, no los fusiona con su twig actual . Esto es particularmente útil si necesita mantener su repository actualizado, pero está trabajando en algo que podría romperse si actualiza sus files. Para integrar los commits en su twig principal, usa merge .

Es importante contrastar la filosofía de layout 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 model de cliente / server. Hay un único repository que es el server, y varios clientes pueden get el código del server, trabajar en él y luego volver a enviarlo al server. La suposition es que el cliente siempre puede contactar al server cuando necesita realizar una operación.

Git fue diseñado para admitir un model más distribuido sin necesidad de un repository central (aunque puede usar uno si lo desea). También git fue diseñado para que el cliente y el "server" no necesiten estar en línea en el Mismo time. 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 model, git mantiene un repository local con su código y también un repository local adicional que refleja el estado del repository remoto. Al mantener localmente una copy del repository remoto, git puede descubrir los cambios necesarios incluso cuando el repository remoto no es accesible. Más tarde, cuando necesite enviar los cambios a otra persona, git puede transferirlos como un set de cambios desde un punto conocido en el repository remoto.

  • git fetch es el command que dice "traer mi copy local del repository remoto actualizada".

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

Normalmente " git pull " hace esto haciendo una " búsqueda de git " para actualizar la copy local del repository remoto, y luego fusionar los cambios en su propio repository de código y posiblemente su copy de trabajo.

Lo importante es tener en count que a menudo hay al less tres copys de un proyecto en su estación de trabajo. Una copy es tu propio repository con tu propio historial de compromisos. La segunda copy es tu copy de trabajo donde estás editando y construyendo. La tercera copy es su copy local "en caching" de un repository remoto.

Aquí está la image de Oliver Steele de cómo todo encaja :

enter image description here

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

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

 git fetch git diff ...origin 

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

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

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

Entonces la diferencia será:

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

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, el origin/master se actualiza pero el master permanece igual).

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

Más

git clone clona un repository.

git rebase guarda cosas de tu twig actual que no está en la twig ascendente a un área temporal. Su sucursal ahora es la misma que antes de comenzar sus cambios. Por lo tanto, git pull -rebase networkingucirá 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.

Además, 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 repository local desde el control remoto (pero no se fusione):

    git fetch

  2. Después de download 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 get más información sobre diferencias entre locales y remotos, consulte: ¿ comparar la twig local de git con la twig remota?

En el paso 3: Es probable que sea más preciso (por ejemplo, en un repository de cambios rápidos) 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/

Algunas veces una representación visual ayuda.

enter image description here

 git-pull - Obtener y fusionarse con otro repository o una twig local
 SINOPSIS

 git pull ...
 DESCRIPCIÓN

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

 Tenga en count que puede usar.  (directory actual) como el <repository> para tirar 
 del repository local: esto es útil cuando se fusionan sucursales locales 
 en la twig actual.

 También tenga en count 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 searchías si solo 'quieres el códec' ya que alguna persona ha estado labelndo algunos artículos aquí.

Puede search desde un repository remoto, ver las diferencias y luego tirar o fusionar.

Este es un ejemplo para un repository remoto llamado origin y una twig llamada master rastrea el origin/master twig remota:

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

La respuesta corta y fácil es que git pull es simplemente git fetch seguido de git merge .

Es muy importante tener en count que git pull se fusionará automáticamente, te guste o no . Esto podría, por supuesto, resultar en conflictos de fusión. Digamos que su control remoto es origin y su twig es master . Si seleccionas git diff origin/master antes de tirar, deberías tener una idea de los posibles conflictos de fusión y podrías preparar tu sucursal local en consecuencia.

Además de tirar y empujar, algunos flujos de trabajo implican 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 una situación git pull --rebase , es posible que tengas la tentación de git pull --rebase . A less que realmente, realmente sepas lo que estás haciendo, te aconsejaría que no lo hicieras. Esta advertencia es de la página man para git-pull , versión 2.3.5 :

Este es un modo de operación potencialmente peligroso. Reescribe la historia, lo que no augura nada cuando ya publicaste ese historial. No use esta opción a less que haya leído git-rebase (1) cuidadosamente.

Me gusta tener una representación visual de la situación para comprender estas cosas. Tal vez a otros desarrolladores les gustaría verlo también, así que aquí está mi adición. No estoy totalmente seguro de que todo sea correcto, así que por favor coméntalo si encuentras 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 recuperado del control remoto son:

  • Rendimiento (desplácese por todas las confirmaciones y posts sin intentar exprimirlo a través de la networking)
  • Comentarios sobre el estado de su repository local (por ejemplo, utilizo SourceTree de Atlassian, que me proporcionará una bombilla que indica si me comprometo por adelantado o por detrás en comparación con el origen. Esta información se puede actualizar con un GET FETCH).

Prima:

Al hablar de pull & fetch en las respuestas anteriores, me gustaría compartir un truco interesante,

git pull --rebase

Este command anterior es el más útil en mi vida git, lo que me ahorró mucho time.

Antes de enviar sus nuevas confirmaciones al server, intente con este command y sincronizará automáticamente los últimos cambios del server (con un fetch + merge) y colocará su confirmación en la parte superior del logging de git. No necesita preocuparse por la extracción manual / fusión.

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

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 repository local. git pull descarga los cambios y los combina en su twig actual. "En su modo pnetworkingeterminado, git pull es una forma abreviada de git fetch seguido de git merge FETCH_HEAD ".

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 image en mi cabeza y decidí tratar de ver el estado de los 2 repositorys y 1 zona de testings y las acciones realizadas a lo largo del time mientras miraba su versión. Así que aquí es lo que se me ocurrió. Por favor corrígeme si lo arruiné en alguna parte.

Los tres repositorys con un scope:

 --------------------- ----------------------- ----------------------- - 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 repositorys 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 muy importante.

We simply say:

 git pull == git fetch + git merge 

If you run git pull , you do not need to merge the data to local. If you run git fetch , it means you must run git merge for getting the latest code to your local machine. Otherwise, the local machine code would not be changed without merge.

So in the Git Gui, when you do fetch, you have to merge the data. Fetch itself won't make the code changes at your local. You can check that when you update the code by fetching once fetch and see; the code it won't change. Then you merge… You will see the changed code.

git fetch pulls down the code from the remote server to your tracking branches in your local repository. If your remote is named origin (the default) then these branches will be within origin/ , for example origin/master , origin/mybranch-123 , etc. These are not your current branches, they are local copies of those branches from the server.

git pull does a git fetch but then also merges the code from the tracking branch into your current local version of that branch. If you're not ready for that changes yet, just git fetch first.

git fetch will retrieve remote branches so that you can git diff or git merge them with the current branch. git pull will run fetch on the remote brach tracked by the current branch and then merge the result. You can use git fetch to see if there are any updates to the remote branch without necessary merging them with your local branch.

Git Fetch

You download changes to your local branch from origin through fetch. Fetch asks the remote repo for all commits that others have made but you don't have on your local repo. Fetch downloads these commits and adds them to the local repository.

Git Merge

You can apply changes downloaded through fetch using the merge command. Merge will take the commits retrieved from fetch and try to add them to your local branch. The merge will keep the commit history of your local changes so that when you share your branch with push, Git will know how others can merge your changes.

Git Pull

Fetch and merge run together often enough that a command that combines the two, pull, was created. Pull does a fetch and then a merge to add the downloaded commits into your local branch.

The only difference between git pull and git fetch is that :

git pull pulls from a remote branch and merges it.

git fetch only fetches from the remote branch but it does not merge

ie git pull = git fetch + git merge …

The Difference between GIT Fetch and GIT Pull can be explained with the following scenario: (Keeping in mind that pictures speak louder than words!, I have provided pictorial representation)

Let's take a example that You are working on a project with your team members. So their will be one main Branch of the project and all the contributors must fork it to their own local repository and then work on this local branch to modify/Add modules then push back to the main branch.

So, Initial State of the two Branches when you forked the main project on your local repository will be like this- (AB,C are Modules already completed of the project)

enter image description here

Now, you have started working on the new module (suppose 'D') and when you have completed the D module you want to push it to the main branch, But meanwhile what happens is that one of your teammates has developed new Module 'E','F' and modified 'C'. So now what has happened is that your local repository is lacking behind the original progress of the project and thus pushing of your changes to main branch can lead to conflict and may cause your Module 'D' to malfunction.

enter image description here

To avoid such issues and to work parallel with the original progress of the project their are Two ways:

1. Git Fetch- This will Download all the changes that have been made to the origin/main branch project which are not present in your local branch. And will wait for the Git Merge command to apply the changes that have been fetched to your Repository or branch.

enter image description here

So now You can carefully monitor the files before merging it to your repository. And you can also modify 'D' if requinetworking because of Modified 'C'.

enter image description here

2. Git Pull- This will update your local branch with the origin/main branch ie actually what it does is combination of Git Fetch and Git merge one after another. But this may Cause Conflicts to occur, so it's recommended to use Git Pull with a clean copy.

enter image description here

Git allows chronologically older commits to be applied after newer commits. Because of this, the act of transferring commits between repositories is split into two steps:

  1. Copying new commits from remote branch to copy of this remote branch inside local repo.

    (repo to repo operation) master@remote >> remote/origin/master@local

  2. Integrating new commits to local branch

    (inside-repo operation) remote/origin/master@local >> master@local

There are two ways of doing step 2. You can:

  1. Fork local branch after last common ancestor and add new commits parallel to commits which are unique to local repository, finalized by merging commit, closing the fork.
  2. Insert new commits after last common ancestor and reapply commits unique to local repository.

In git terminology, step 1 is git fetch , step 2 is git merge or git rebase

git pull is git fetch and git merge

What is the difference between git pull and git fetch ?

To understand this, you first need to understand that your local git maintains not only your local repository, but it also maintains a local copy of the remote repository.

git fetch brings your local copy of the remote repository up to date. For example, if your remote repository is GitHub – you may want to fetch any changes made in the remote repository to your local copy of it the remote repository. This will allow you to perform operations such as compare or merge.

git pull on the other hand will bring down the changes in the remote repository to where you keep your own code. Typically, git pull will do a git fetch first to bring the local copy of the remote repository up to date, and then it will merge the changes into your own code repository and possibly your working copy.

OK , Here are some information about git pull and git fetch , so you can understand the actual differences… in simple words, fetch gets the latest data, but not the code changes and not going to mess with your current code, but pull get the code changes and merge it your local branch, read on to get more details about each:

git fetch

It will download all refs and object and any new branches to local Repository…

Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of below for ways to control this behavior).

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the –tags or –no-tags options or by configuring remote..tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.

git fetch can fetch from either a single named repository or URL, or from several repositories at once if is given and there is a remotes. entry in the configuration file. (See git-config 1 ).

When no remote is specified, by default the origin remote will be used, unless there's an upstream branch configunetworking for the current branch.

The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by scripts or other git commands, such as git-pull.


git pull

It will apply the changes from remote to the current branch in local…

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With –rebase, it runs git rebase instead of git merge.

should be the name of a remote repository as passed to git-fetch 1 . can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (eg, refs/heads/ :refs/remotes/origin/ ), but usually it is the name of a branch in the remote repository.

Default values for and are read from the "remote" and "merge" configuration for the current branch as set by git-branch –track.


I also create the visual below to show you how git fetch and git pull working together…

git pull and git fetch

Git obtains the branch of the latest version from the remote to the local using two commands:

  1. git fetch: Git is going to get the latest version from remote to local, but it do not automatically merge. git fetch origin master git log -p master..origin/master git merge origin/master

    The commands above mean that download latest version of the main branch from origin from the remote to origin master branch. And then compares the local master branch and origin master branch. Finally, merge.

  2. git pull: Git is going to get the latest version from the remote and merge into the local.

    git pull origin master

    The command above is the equivalent to git fetch and git merge . In practice, git fetch maybe more secure because before the merge we can see the changes and decide whether to merge.

git pull == ( git fetch + git merge)

git fetch does not changes to local branches.

If you already have a local repository with a remote set up for the desinetworking project, you can grab all branches and tags for the existing remote using git fetch . … Fetch does not make any changes to local branches, so you will need to merge a remote branch with a paird local branch to incorporate newly fetch changes. from github

Trying to be clear and simple.

The git pull command is actually a shortcut for git fetch followed by the git merge or the git rebase command depending on your configuration. You can configure your Git repository so that git pull is a fetch followed by a rebase.

Actually Git maintains a copy of your own code and the remote repository.

The command git fetch makes your local copy up to date by getting data from remote repository. The reason we need this is because somebody else might have made some changes to the code and you want to keep yourself updated.

The command git pull brings the changes in the remote repository to where you keep your own code. Normally, git pull does this by doing a 'git fetch' first to bring the local copy of the remote repository up to date, and then it merges the changes into your own code repository and possibly your working copy.

From Pro Git § 2.5 Git Basics – Working with Remotes: Fetching and Pulling from Your Remotes :

It's important to note that the fetch command pulls the data to your local repository — it doesn't automatically merge it with any of your work or modify what you're currently working on. You have to merge it manually into your work when you're ready.

If you have a branch set up to track a remote branch, you can use the git pull command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from (assuming the remote has a master branch). Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.

 git pull = git fetch + git merge