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

Question

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

В чем различия между git pull и git fetch?

Answer 1

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

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

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

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

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

В режиме по умолчанию git pull является сокращением для git fetch, за которым следует git merge FETCH_HEAD.

Answer 2

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

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

Answer 3

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

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

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

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

• git fetch - это команда, которая говорит «обновить мою локальную копию удаленного хранилища».

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

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

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

Answer 4

Вот Образ Оливера Стила о том, как все это сочетается вместе :

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

Answer 5

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

git fetch
git diff ...origin

Answer 6

Мне стоило немного понять, в чем разница, но это простое объяснение. master на вашем локальном хосте есть ветка.

Когда вы клонируете репозиторий, вы получаете весь репозиторий на свой локальный хост. Это означает, что в это время у вас есть указатель источника / мастера на HEAD и мастер, указывающий на тот же HEAD.

когда вы начинаете работать и делаете коммиты, вы переводите главный указатель на HEAD + ваши коммиты. Но указатель источника / мастера все еще указывает на то, что было, когда вы клонировали.

Так что разница будет:

• Если вы сделаете git fetch, он просто извлечет все изменения в удаленном хранилище ( GitHub ) и переместит указатель источника / мастера на HEAD. Тем временем ваш местный руководитель филиала будет продолжать указывать, где он находится.
• Если вы сделаете git pull, он будет в основном извлекать (как объяснено ранее) и объединять любые новые изменения с вашей основной веткой и перемещать указатель на HEAD.

Answer 7

Иногда помогает визуальное представление.

Answer 8

Коротко

git fetch похоже на pull, но не сливается. то есть он выбирает удаленные обновления (refs и objects), но ваш локальный остается прежним (то есть origin/master обновляется, но master остается прежним).

git pull срывается с пульта и мгновенно сливается.

Подробнее

git clone клонирует репо.

git rebase сохраняет данные из вашей текущей ветки, которые не находятся в восходящей ветке, во временную область. Ваша ветка теперь такая же, как и до того, как вы начали свои изменения. Таким образом, git pull -rebase будет снимать удаленные изменения, перематывать вашу локальную ветку, воспроизводить ваши изменения поверх текущей ветки один за другим, пока вы не будете в курсе.

Кроме того, git branch -a точно покажет вам, что происходит со всеми вашими филиалами - локальными и удаленными.

Этот пост был полезен:

Разница между git pull, git fetch и git clone (и git rebase) - Майк Пирс

и обложки git pull, git fetch, git clone и git rebase.

====

UPDATE

Я думал, что обновлю это, чтобы показать, как вы на самом деле используете это на практике.

1. Обновите локальный репозиторий с пульта (но не объединяйте):

   git fetch 
   

2. После загрузки обновлений, давайте посмотрим на различия:

   git diff master origin/master 
   

3. Если вы довольны этими обновлениями, то объедините:

   git pull
   

Примечания:

На шаге 2: Подробнее о различиях между локальным и удаленным интерфейсом см. Как сравнить локальную ветку git с ее удаленной веткой?

На шаге 3: вероятно, более точно (например, в быстро меняющемся репо) сделать git rebase origin здесь. См. @ комментарий Джастина Ома в другом ответе.

Смотри также: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

Answer 9

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.

Вы бы потянули, если хотите, чтобы истории были объединены, вы извлекли бы, если бы вы просто «хотели кодез», поскольку какой-то человек отмечал некоторые статьи здесь.

Answer 10

Вы можете получить из удаленного хранилища, увидеть различия, а затем вытащить или объединить.

Это пример удаленного хранилища с именем origin и ветки с именем master, отслеживающей удаленную ветку origin/master:

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