Вопрос: В чем разница между «git pull» и «git fetch»?


Примечание модератора: Учитывая, что этот вопрос уже шестьдесят четыре ответа отправил на рассмотрение вопрос о том, являетесь ли вы внося что-то новое перед публикацией другого.

Каковы различия между git pullа также git fetch?


9964


источник


Ответы:


Проще говоря, git pullделает git fetchа затем git merge,

Вы можете сделать git fetchв любое время, чтобы обновить ветки удаленного отслеживания refs/remotes/<remote>/,

Эта операция никогда не изменяет ни одно из ваших собственных локальных refs/heads, и безопасно обойтись без изменения рабочей копии. Я даже слышал о людях, бегущих git fetchпериодически в задании cron в фоновом режиме (хотя я бы не рекомендовал это делать).

git pullэто то, что вы бы сделали, чтобы обновить локальный филиал с помощью своей удаленной версии, а также обновить другие ветви удаленного отслеживания.

Документация Git: git pull


8349



  • Когда вы используете pull, Git пытается автоматически выполнить вашу работу за вас. Это контекстно-зависимая , поэтому Git объединит любые потянутые фиксации в ветку, в которой вы сейчас работаете. pull автоматически объединяет коммиты, не давая вам сначала просмотреть их , Если вы не контролируете свои филиалы, вы можете столкнуться с частыми конфликтами.

  • Когда ты fetch, Git собирает любые фиксации из целевой ветви, которые не существуют в вашей текущей ветке и хранит их в вашем локальном хранилище , Однако, он не объединяет их с вашей текущей ветвью , Это особенно полезно, если вам нужно постоянно обновлять свой репозиторий, но работайте над тем, что может сломаться, если вы обновите свои файлы. Чтобы интегрировать коммиты в основную ветку, вы используете merge,


1824



Важно противопоставить философию дизайна git философией более традиционного инструмента управления источниками, таким как SVN.

Subversion была разработана и построена с использованием модели клиент / сервер. Существует один репозиторий, который является сервером, и несколько клиентов могут извлекать код с сервера, работать с ним, а затем передавать его обратно на сервер. Предполагается, что клиент всегда может связаться с сервером, когда ему нужно выполнить операцию.

Git был разработан для поддержки более распределенной модели без необходимости в центральном репозитории (хотя вы, безусловно, можете использовать его, если хотите). Также git был разработан таким образом, что клиент и «сервер» не должны быть в сети одновременно. Git был разработан так, чтобы люди на ненадежной ссылке могли даже обменять код по электронной почте. Можно полностью отключить работу и записать компакт-диск для обмена кодом через git.

Для поддержки этой модели git поддерживает локальный репозиторий с вашим кодом, а также дополнительный локальный репозиторий, который отражает состояние удаленного репозитория. Сохраняя копию удаленного репозитория локально, git может определить изменения, необходимые, даже если удаленный репозиторий недоступен. Позже, когда вам нужно отправить изменения кому-то другому, git может передать их как набор изменений с момента времени, известного удаленному репозиторию.

  • git fetchэто команда, которая говорит: «Довести мою локальную копию удаленного репозитория до последней версии».

  • git pullговорит: «Принесите изменения в удаленный репозиторий, где я сохраню свой собственный код».

Как обычно git pullделает это, выполняя git fetchчтобы обновить локальную копию удаленного репозитория, а затем объединить изменения в свой собственный репозиторий кода и, возможно, вашу рабочую копию.

Убрать это, чтобы иметь в виду, что часто существует не менее три экземпляра проекта на вашей рабочей станции. Один экземпляр - это ваш собственный репозиторий со своей собственной историей фиксации. Вторая копия - это ваша рабочая копия, где вы редактируете и строите. Третья копия - это ваша локальная «кэшированная» копия удаленного репозитория.


987



Здесь Образ Оливера Стил, как все это сочетается :

enter image description here

Если есть достаточный интерес, я полагаю, что я мог бы обновить изображение, чтобы добавить git cloneа также git merge...


633



One use case of git fetch is that the following will tell you any changes in the remote branch since your last pull... so you can check before doing an actual pull, which could change files in your current branch and working copy.

git fetch
git diff ...origin

422



It cost me a little bit to understand what was the difference, but this is a simple explanation. master in your localhost is a branch.

When you clone a repository you fetch the entire repository to you local host. This means that at that time you have an origin/master pointer to HEAD and master pointing to the same HEAD.

when you start working and do commits you advance the master pointer to HEAD + your commits. But the origin/master pointer is still pointing to what it was when you cloned.

So the difference will be:

  • If you do a git fetch it will just fetch all the changes in the remote repository (GitHub) and move the origin/master pointer to HEAD. Meanwhile your local branch master will keep pointing to where it has.
  • If you do a git pull, it will do basically fetch (as explained previously) and merge any new changes to your master branch and move the pointer to HEAD.

339



Sometimes a visual representation helps.

enter image description here


176



Briefly

git fetch is similar to pull but doesn't merge. i.e. it fetches remote updates (refs and objects) but your local stays the same (i.e. origin/master gets updated but master stays the same) .

git pull pulls down from a remote and instantly merges.

More

git clone clones a repo.

git rebase saves stuff from your current branch that isn't in the upstream branch to a temporary area. Your branch is now the same as before you started your changes. So, git pull -rebase will pull down the remote changes, rewind your local branch, replay your changes over the top of your current branch one by one until you're up-to-date.

Also, git branch -a will show you exactly what’s going on with all your branches - local and remote.

This blog post was useful:

The difference between git pull, git fetch and git clone (and git rebase) - Mike Pearce

and covers git pull, git fetch, git clone and git rebase.

====

UPDATE

I thought I'd update this to show how you'd actually use this in practice.

  1. Update your local repo from the remote (but don't merge):

    git fetch

  2. After downloading the updates, let's see the differences:

    git diff master origin/master

  3. If you're happy with those updates, then merge:

    git pull

Notes:

On step 2: For more on diffs between local and remotes, see: compare local git branch with remote branch?

On step 3: It's probably more accurate (e.g. on a fast changing repo) to do a git rebase origin here. See @Justin Ohms comment in another answer.

See also: http://longair.net/blog/2009/04/16/git-fetch-and-merge/


163



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.

You would pull if you want the histories merged, you'd fetch if you just 'want the codez' as some person has been tagging some articles around here.


154



You can fetch from a remote repository, see the differences and then pull or merge.

This is an example for a remote repository called origin and a branch called master tracking the remote branch origin/master:

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

141