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

вопрос создан в Sat, Nov 3, 2018 12:00 AM
  

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

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

    
11047
  1. Я нашел эту хорошо написанную статью о git fetch и git pull, которую стоит прочитать: longair.net/blog/2009/04/16/git-fetch-and-merge
    2010-09-16 06: 57: 47Z
  2. Наш альтернативный подход стал git fetch; git reset --hard origin/master как часть нашего рабочего процесса. Он сносит локальные изменения, держит вас в курсе событий, но мастер гарантирует, что вы не просто добавите новые изменения поверх текущих изменений и создадите беспорядок. Мы использовали его некоторое время, и на практике это выглядит намного безопаснее. Просто убедитесь, что сначала добавили /зафиксировали /спрятали любую незавершенную работу!
    2014-05-04 14: 32: 18Z
  3. Убедитесь, что вы знаете, как правильно использовать git stash. Если вы спрашиваете о 'pull' и 'fetch', то, возможно, 'stash' также потребует объяснения ...
    2014-12-09 20: 09: 04Z
  4. Многие люди из Mercurial продолжают использовать "git pull", думая, что это эквивалентно "hg pull". Что это не так. Git эквивалентно «hg pull» - это «git fetch».
    2015-06-29 10: 15: 53Z
  5. команда git fetch, извлекающая обновленный код с веткой, а также получит новые добавленные ветки в вашей локальной системе, команда git pull извлекает только обновленный код только текущей ветки
    2017-07-27 11: 43: 31Z
30 ответов                              30                         

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

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

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

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

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

  

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

    
9187
2019-05-02 18: 52: 15Z
  1. "" git pull "- это то, что вы хотели бы сделать, чтобы ваш репозиторий обновлялся" < - разве обновление репозитория уже не было выполнено fetch? Разве вы не имеете в виду, что это приводит ваши местные филиалы в соответствие с удаленными филиалами? Чтобы объединить: он объединяет удаленные ветви с вашими локальными копиями этих веток, или что именно здесь объединяется?
    2009-11-10 12: 13: 21Z
  2. @ Альберт: Да, это странно. git pull всегда будет сливаться с текущей веткой . Таким образом, вы выбираете, какую ветвь вы хотите получить из , и она вытягивает ее в текущую ветку. Ветвь from может быть локальной или удаленной; это может быть даже удаленная ветвь, которая не является зарегистрированным git remote (то есть вы передаете URL-адрес в командной строке git pull).
    2010-06-06 10: 10: 08Z
  3. @ espertus: Нет. Нажатие никогда не приводит к автоматическому слиянию. Ожидается, что пользователь извлечет данные, разрешив любые конфликты слияния локально, затем вернитесь к удаленному.
    2011-03-17 00: 41: 04Z
  4. Если я нахожусь на /home/alice/ и делаю git fetch /home/bob, какие параметры я должен передать последующим git merge?
    2011-05-27 19: 38: 02Z
  5. Примечание для людей, изучающих Git: на самом деле pull нельзя эмулировать с помощью fetch плюс merge. Я только что получил изменение, при котором меняется только указатель удаленной ветви, а merge отказывается что-либо делать. pull, с другой стороны, ускоряет мою ветвь отслеживания.
    2012-09-28 16: 23: 00Z
  • Когда вы используете pull, Git пытается автоматически выполнить вашу работу за вас. Он чувствителен к контексту , поэтому Git объединит все запрошенные коммиты с веткой, в которой вы сейчас работаете. pull автоматически объединяет коммиты, не давая вам предварительно просмотреть их . Если вы плохо управляете своими ветками, вы можете столкнуться с частыми конфликтами.

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

2022
2015-04-18 18: 47: 14Z
  1. Согласен, отличный комментарий. Вот почему я ненавижу мерзавца. Когда было бы когда-нибудь целесообразно, чтобы инструмент редактирования вносил изменения для вас? И разве это не то, что делает слияние двух файлов? Что если эти две правки физически разделены в файле, но ЛОГИЧЕСКИ по коэффициенту?
    2013-05-13 18: 44: 23Z
  2. @ Если коротко, elexhobby, git fetch обновляет только ваш каталог .git/ (AKA: локальный репозиторий) и ничего за пределами .git/ (AKA: рабочее дерево). Это не меняет ваши местные филиалы, и это также не касается master. Хотя это касается remotes/origin/master (см. git branch -avv). Если у вас есть больше пультов, попробуйте git remote update. Это git fetch для всех пультов в одной команде.
    2013-07-17 06: 48: 09Z
  3. @ Тино ваш действительно самый важный момент. Люди могут не знать, что «удаленные» ветки на самом деле хранятся в виде набора хэшей в .git/refs/remotes/origin/.
    2013-09-12 21: 49: 41Z
  4. Когда вы выбираете, Git собирает любые коммиты из целевой ветки, которых нет в вашей текущей ветке, и сохраняет их в вашем локальном репозитории - как посмотреть, что было принесено с пульта и как объединить его с местными филиалами?
    2014-06-13 01: 40: 52Z
  5. @ Tino Чего я до сих пор не понимаю, так это ... какой в ​​этом смысл? Зачем использовать fetch, если он только обновляет .git? Какова предполагаемая выгода и что я должен делать после этого?
    2016-03-23 ​​12: 19: 54Z

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

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

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

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

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

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

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

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

    
1125
2018-08-24 20: 01: 19Z
  1. Технически, локальные и удаленные репозитории действительно одно и то же. В Git репозиторий представляет собой DAG коммитов, указывающих на их родителей. С технической точки зрения ветви - это не более чем значимые имена коммитов. Единственное различие между локальной и удаленной ветвями состоит в том, что к удаленным ветвям добавляется remoteName/ Git с нуля - очень хорошее чтение. Как только вы получите представление о том, как работает Git - и это красиво просто , на самом деле - все становится понятным.
    2013-08-14 09: 51: 05Z
  2. Большое спасибо за объяснение. До сих пор я не понимал, что Git был разработан, поэтому вам не нужно иметь центральный репозиторий. Все всегда говорят «DVCS» при описании Git, но как относительно новый программист, это ничего не значит для меня. Я никогда не видел CVCS, и я также никогда не работал с центральным удаленным репозиторием при сотрудничестве с другими (например, Github), поэтому до сих пор я еще не понял, что делает Git особенным .
    2013-08-15 02: 17: 04Z
  3. Итак, исходя из этого, почему НЕ ГОДИМАЯ ГИТ-выборка с заданием cron? Всегда рекомендуется хранить копию пульта, с которым вы работаете, на локальном компьютере. На самом деле мне хочется написать скрипт, который проверяет, обновил ли я свой пульт за последние 24 часа, и связал его с помощью ловушки udev для подключения к интернету.
    2013-08-15 02: 23: 38Z
  4. Одна из причин, почему не стоит иметь задание cron: часто при работе с новым тикетом или при обновлении ветки мне нравится увидеть изменения, которые будут получены. Если изменения не произойдут во время выборки, я буду более уверенно спрашивать моего коллегу-программиста: «Эй, ты подтолкнул?». Я также чувствую, сколько «оттока» в хранилище с момента последней загрузки. Это также помогает мне понять количество и скорость изменений, которые в настоящее время вносятся в этот репозиторий.
    2014-07-23 11: 47: 01Z
  5. @ Nabheet Дело в том, что Git ориентирован на контент. Он хранит данные только один раз и указывает на это несколькораз. Вот почему в Git даже несколько коммитов поверх оригинала не сильно влияют на размер репо, поскольку большинство объектов одинаковы.
    2016-11-05 09: 43: 18Z

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

введите описание изображения здесь

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

    
775
2018-03-19 19: 21: 23Z
  1. Было бы очень полезно обновить изображение с git clone и git merge!
    2015-09-08 14: 23: 51Z
  2. Да, пожалуйста, добавьте git merge - это должно ясно показать, что merge, вызываемый отдельно, НЕ совпадает с вызовом pull, потому что pull объединяется только с удаленного компьютера и игнорирует ваши локальные коммиты в вашем локальная ветвь, которая отслеживает удаленную ветку, из которой извлекаются.
    2015-10-21 19: 57: 33Z
  3. Картинка стоит тысячи слов! Обновленное изображение с потоком данных клонирования и слияния где-нибудь готово? Любой другой поток данных помимо того, что уже есть на диаграмме?
    2015-11-25 00: 27: 05Z
  4. @ Contango, пожалуйста, добавьте клон и объедините. Будет полезно для таких новичков, как я.
    2016-01-15 16: 02: 32Z
  5. Существуют две диаграммы, показывающие клонирование и слияние в других ответах (ниже) с помощью th3sly и thedarkpassenger.
    2016-08-12 00: 42: 46Z

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

git fetch
git diff ...origin
    
455
2013-08-01 19: 38: 09Z
  1. Отличное дополнение! Меня смутили точки, не так ли: git diff origin
    2010-07-27 12: 15: 09Z
  2. почему бы не git diff ..origin?
    2012-02-12 23: 47: 33Z
  3. git diff origin и git diff ..origin, похоже, работают, но не так странно ... stuff
    2013-01-08 19: 32: 06Z
  4. @ Compustretch Не должно быть пробела. git diff ...origin эквивалентно git diff $(git-merge-base HEAD origin) origin (см. Раздел git diff [--options] <commit>...<commit> [--] [<path>…] в kernel.org/pub/software/scm/git/docs/git-diff.html#_description ), который отличается от git diff origin; Концептуально git diff ...origin - это изменения, внесенные в origin, поскольку текущая ветвь ветвится с origin, в то время как git diff origin включает в себя также обратную сторону изменений, внесенных в текущую ветвь, поскольку она ветвится с origin.
    2013-08-01 19: 34: 28Z
  5. ни одна из команд .. не работала для меня (в Windows), но git diff origin/master работает, как указано ниже
    2014-02-20 09: 07: 13Z

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

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

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

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

  • Если вы сделаете git fetch, он просто загрузит все изменения в удаленном хранилище ( GitHub ) и переместите указатель источника /мастера на HEAD. Тем временем ваш локальный руководитель филиала будет продолжать указывать, где он находится.
  • Если вы сделаете git pull, он будет в основном извлекать (как объяснено ранее) и объединять любые новые изменения в вашей основной ветви и перемещать указатель на HEAD.
356
2016-01-02 04: 52: 49Z
  1. origin /master - это локальная ветвь, которая является копией master на origin. Когда вы выбираете, вы обновляете local: /origin /master. Как только вы действительно поймете, что все в git - это ветвь, это имеет большой смысл и является очень мощным способом поддержания различных наборов изменений, быстрого локального ветвления, слияния и перебазирования, и, как правило, извлекает большую пользу из дешевого ветвления. модель.
    2013-05-28 16: 00: 14Z
  2. Все еще сбивает с толку. Я думал, что git fetch должен был буквально загружать изменения на удаленном репо в ваше локальное репо, но НЕ фиксировать их - то есть, они все еще должны быть добавлены /зафиксированы в вашем локальном репо.
    2015-02-26 14: 57: 50Z
  3. извлекает только извлечения из удаленного /origin (github) к вашему локальному источнику. Но это не объединяет его с вашими фактическими рабочими файлами. если вы делаете вытягивание, оно извлекается и сливается с вашими текущими рабочими файлами
    2015-02-26 19: 45: 36Z

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

 введите описание изображения здесь

    
202
2016-01-25 17: 28: 50Z
  1. Я думаю, что картинка должна показать, что она также влияет на локальное репо. То есть Git pull - это комбинация влияния на локальный репо и рабочую копию. Сейчас кажется, что это влияет на рабочую копию.
    2016-02-14 18: 51: 46Z
  2. @ @ 生 者 無極 而 生 Согласовано - это изображение вводит в заблуждение, потому что выглядит так, как будто git pull пропускает выборку, которая конечно неточно.
    2016-08-20 15: 33: 23Z
  3. в чем разница между «локальным репозиторием» и «рабочей копией»? Разве они не локальны на компьютере?
    2017-11-16 03: 12: 58Z
  4. В чем тогда смысл использования git fetch? как узнать, какая разница в локальном хранилище и рабочей копии?
    2019-03-13 06: 56: 33Z
  5. @ theITvideos Нет, это не так. Локальный репозиторий - это то место, куда отправляется ваш код (из рабочего репозитория) при фиксации. (Это происходит в удаленном репо, когда вы нажимаете).
    2019-03-13 06: 59: 04Z

Коротко

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.

==== р>

ОБНОВЛЕНИЕ р>

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

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

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

     
    git diff master origin/master 
    
  3. Если вы довольны этими обновлениями, объедините их.

     
    git pull
    

Примечания:

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

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

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

    
195
2018-11-28 20: 18: 32Z
  1. Похоже, если кто-то просто хочет, чтобы локальный код отражал "подсказку", он должен использовать git clone. Я поместил подсказку в кавычки, поскольку я предполагаю, что это будет означать, какой бы мастер ни был, и что кто-то будет «скачать как zip» с github.com
    2013-09-12 08: 27: 15Z
  2. что, если вы не довольны изменениями после git fetch? что делать дальше?
    2015-03-24 06: 06: 37Z
  3. Ваш абзац о rebase был именно тем, что я искал. Сама идея обнуления всего, обновления с удаленного компьютера, а затем воспроизведения ваших изменений поверх предыдущих коммитов , которые произошли во время вашей работы. Идеальное объяснение при условии, что это правильно. ;)
    2016-03-03 00: 01: 20Z
 
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.

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

    
168
2008-11-15 09: 52: 50Z
  1. Очень интересно, но я действительно не вижу варианта использования, когда вы хотите "просто код". И что происходит с вашим кодом при получении? Это стерто? Что происходит при смене пульта? Как это отражается на вашем репо без стирания кода, если вы не объединяетесь?
    2010-03-27 16: 21: 55Z
  2. @ e-sat: Удаленная ветвь также хранится локально на вашем компьютере. Поэтому, когда вы делаете git fetch, он выбирает изменения из хранилища и обновляет вашу локальную удаленную ветку. Это не влияет на вашу местную ветку, которая отслеживает локальный удаленный бюстгальтернч, так не влияет на вашу рабочую копию. Теперь, когда вы делаете merge, он объединит извлеченные изменения с вашей локальной веткой.
    2011-10-31 04: 23: 36Z
  3. Простой вариант использования команды fetch: выполняйте трудоемкие операции, включающие недавние коммиты других людей, такие как слияние или просмотр кода, получая доступ только к вашим последним датируйте локальный репозиторий без требований к сетевому соединению, потому что вы ранее использовали fetch для быстрой загрузки всего, что вам нужно (например, когда вы посещаете какого-то другого разработчика и подключены к сети другого репозитория). Команда pull загружает те же самые коммиты, но выполняемое слияние может быть нежелательным.
    2013-09-19 10: 25: 33Z

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

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

 
git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master
    
153
2015-03-15 22: 20: 04Z
  1. Возможно, вы захотите пропустить извлечение и просто сделать «источник git rebase» в качестве последнего шага, так как вы уже получили изменения. Причина в том, что кто-то мог сдвинуть изменения во времени, с тех пор как вы сделали выборку, и они не были бы в той загрузке, в которой вы делали обзор различий.
    2012-08-31 20: 02: 48Z

Короткий и простой ответ: git pull - это просто git fetch, за которым следует git merge.

Очень важно отметить, что git pull автоматически объединится, нравится вам это или нет . Это может, конечно, привести к конфликтам слияния. Допустим, ваш пульт origin, а филиал master. Если у вас git diff origin/master до того, как вы потянете, у вас должно быть представление о потенциальных конфликтах слияний, и вы можете соответствующим образом подготовить свой местный филиал.

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

 
git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

Если вы окажетесь в такой ситуации, у вас может возникнуть соблазн на git pull --rebase. Если вы действительно, действительно не знаете, что делаете, я бы посоветовал против этого. Это предупреждение со страницы man для git-pull, версия 2.3.5:

  

Это потенциально опасный режим работы. Переписывает   история, которая не сулит ничего хорошего, когда вы опубликовали эту историю   уже. Не используйте эту опцию, если вы не читали git-rebase (1)   тщательно.

    
145
2018-09-24 15: 28: 49Z
  1. @ JustinOhms Если git pull --rebase не подходит для данной ситуации, правильно ли это, если сделать это в два этапа? Если это правильно, какая польза от этого в два этапа?
    2013-05-23 21: 56: 38Z
  2. @ Kaz - потому что перебазирование не является автоматическим. Извлечение изменений в первую очередь позволяет вам принять решение. Это не решает проблему с перебазированием истории, которую вы уже выдвинули. Это позволит вам проверить, насколько безопасно отменить изменения, которые вы еще не отправили.
    2013-05-24 21: 11: 52Z
  3. @ JustinOhms Как вы решите, насколько безопасно отменить изменения? Я просто попробовал бы git rebase и backtrack, если он сделал беспорядок, и в этом случае я мог бы также сделать git pull --rebase. Но, может быть, у вас есть другой способ?
    2013-05-25 06: 14: 19Z
  4. @ KaZ gitk позволяет вам визуально видеть структуру ветки. Она покажет вам положение вашей локальной головы, удаленных устройств и ваших структур ветки относительно того, что вы выбрали. Таким образом, вы можете быть уверены, что вы не перебазируете извлеченные изменения, основанные на предке, предшествующем тому, что вы уже отправили на пульт (ы).
    2013-05-28 19: 18: 02Z
  5. Используйте rebase, когда вы работаете с локальной ветвью, которая еще не нажата. Если вы работаете над веткой, существующей на удаленном компьютере, rebase может привести к некоторым неприятным проблемам, поэтому вам следует выбрать обычный merge.
    2014-12-01 08: 39: 57Z

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

git fetch

Он загрузит все ссылки и объекты и все новые ветви в ваш локальный репозиторий ...

  

Извлекать ветки и /или теги (вместе "refs") из одного или нескольких   другие хранилища, а также объекты, необходимые для завершения их   истории. Обновлены ветки удаленного слежения (см. Описание   ниже для способов управления этим поведением).

     

По умолчанию любой тег, который указывает на историю выборки,   также извлечен; Эффект заключается в получении тегов, которые указывают на ветви, которые   Вы заинтересованы. Это поведение по умолчанию может быть изменено с помощью   параметры --tags или --no-tags или путем настройки   remote..tagOpt. Используя refspec, который явно выбирает теги,   Вы можете выбрать теги, которые не указывают на интересующие вас ветки   в том числе.

     

git fetch может извлекать данные либо из одного именованного репозитория, либо по URL, либо   из нескольких репозиториев одновременно, если дано и есть   пульты дистанционного управления. запись в файле конфигурации. (См. Git-config 1 ).

     

Если удаленный не указан, по умолчанию исходный удаленный   используется, если нет восходящей ветви, настроенной для текущего   ветвь.

     

Имена ссылок, которые выбираются вместе с именами объектов.   они указывают на, записаны в .git /FETCH_HEAD. Эта информация может быть   используется скриптами или другими командами git, такими как git-pull.

git pull

Он применит изменения из удаленного в текущую ветку в локальном ...

  

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

     

Точнее, git pull запускает git fetch с заданными параметрами и   вызывает git merge, чтобы объединить полученные заголовки веток с текущим   ветка. С --rebase он запускает git rebase вместо git merge.

     

должно быть именем удаленного репозитория, переданного в   git-fetch 1 . можно назвать произвольную удаленную ссылку (например,   имя тега) или даже сборник ссылок с соответствующими   ветви удаленного отслеживания (например, refs /heads /: refs /remotes /origin /),   но обычно это имя ветки в удаленном хранилище.

     

Значения по умолчанию для и считываются из   «Удаленная» и «объединить» конфигурации для текущей ветви, как установлено   git-branch --track.

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

 git pull и git fetch

    
129
2018-09-28 10: 38: 33Z
  1. Если вам нравится изображение, взгляните на шпаргалку git, которая одинакова для всех команд git ... ndpsoftware.com/git-cheatsheet.html
    2018-05-20 16: 42: 23Z
  2. Не влияет ли клонирование также на локальный репозиторий (копирование всей истории с удаленного компьютера)?
    2018-07-04 04: 38: 54Z

введите описание изображения здесь

Это интерактивное графическое представление очень помогает в понимании мерзавца: http://ndpsoftware.com/git-cheatsheet.html

git fetch просто «загружает» изменения с удаленного в ваш локальный репозиторий. git pull загружает изменения и объединяет их с вашей текущей веткой. «В режиме по умолчанию git pull - это сокращение от git fetch, за которым следует git merge FETCH_HEAD».

    
123
2016-12-09 10: 02: 01Z
  1. Люди, нажмите на ссылку, чтобы взаимодействовать с различными столбцами. Этот чит-лист - лучший ресурс, который я видел, чтобы полностью понять различия между каждой командой.
    2016-10-04 00: 41: 48Z

Бонус:

Говоря о pull & Получить в ответах выше, я хотел бы поделиться интересным трюком,

git pull --rebase

Эта команда является самой полезной в моей жизни в git, которая сэкономила много времени.

Прежде чем отправлять ваши новые коммиты на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения на сервере (с извлечением + слиянием) и поместит ваш коммит наверху в git log. Не нужно беспокоиться о ручном вытягивании /слиянии.

Подробности можно найти по адресу: http://gitolite.com/git-pull--rebase р>     

119
2016-08-08 16: 56: 17Z
  1. Хороший совет, хотя для новых пользователей git стоит упомянуть, что rebase изменяет хеши коммитов (я обнаружил, что это удивительно из-за подрывной деятельности).
    2016-09-20 12: 57: 00Z
  2. Можете ли вы объяснить, в чем разница между git pull и git pull --rebase?
    2018-01-17 07: 02: 10Z
  3. См. серьезное предупреждение об этом методе в ответе выше: stackoverflow.com /а /6011169/241244
    2018-10-24 08: 00: 20Z

Мне нравится иметь некоторое визуальное представление ситуации, чтобы понять эти вещи. Может быть, другие разработчики тоже захотят это увидеть, так что вот мое дополнение. Я не совсем уверен, что все правильно, поэтому, пожалуйста, прокомментируйте, если обнаружите какие-либо ошибки.

 
                                         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.

Некоторые основные преимущества наличия удаленного зеркала пульта:

  • Производительность (просматривайте все коммиты и сообщения, не пытаясь протолкнуть их через сеть)
  • Отзывы о состоянии вашего локального репо (например, я использую SourceTree от Atlassian, что даст мне лампочку, указывающую, что я совершаю коммит вперед или назад по сравнению с источником. Эта информация может быть обновлена ​​с помощью GIT FETCH).
111
2014-07-25 07: 01: 35Z
  1. Разве git pull также не выполняет слияние, то есть весь путь до рабочей копии?
    2014-03-24 17: 28: 47Z
  2. Хороший вопрос, да, он внесет все изменения в вашу рабочую копию, а затем вы сможете зафиксировать ее самостоятельно в локальном репо. Я буду обновлять визуальный.
    2014-03-25 07: 50: 20Z
  3. @ JustusRomijn Разве pull также не обновляет локальный репозиторий? Разве не должно быть звездочки между звездочками источника и рабочей копии?
    2015-01-08 09: 34: 07Z
  4. @ user764754 Когда вы извлекаете изменения, ваша рабочая копия получает изменения (также могут быть некоторые конфликты, которые вам, возможно, придется решить). Вы все еще должны зафиксировать это в своем локальном хранилище.
    2015-01-12 07: 17: 24Z
  5. @ JustusRomijn: Спасибо за иллюстрацию. Было бы здорово, если бы вы могли сделать диаграмму более полной, иллюстрируя эффекты таких операций, как сброс, выбор вишни в хранилище состояния.
    2015-01-17 12: 42: 39Z

Я тоже с этим боролся. На самом деле я попал сюда с поиском в Google точно такого же вопроса. Чтение всех этих ответов, наконец, нарисовало картину в моей голове, и я решил попытаться разобраться в этом, глядя на состояние 2 репозиториев и 1 песочницы и действий, выполненных с течением времени, во время просмотра их версии. Итак, вот что я придумала. Пожалуйста, поправьте меня, если я что-то напутал.

Три репо с извлечением:

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

Три репо с вытягиванием

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

Это помогло мне понять, почему выборка очень важна.

    
102
2017-05-31 19: 41: 16Z
  1. Не так сложно прочитать: поля представляют состояние репо, которое в каждой строке изменяется во времени слева направо после сообщаемой операции в строке 2 коробка. Метки R0n - это теги в git, а тег с + - это еще не загруженный материал. Sanbox используется для вашей рабочей папки, которая отличается от папки репо, где хранятся зафиксированные данные.
    2017-08-30 07: 57: 02Z

Разницу между GIT Fetch и GIT Pull можно объяснить следующим сценарием: (Помните, что картинки говорят громче слов! Я предоставил графическое представление)

Давайте рассмотрим пример, когда вы работаете над проектом с членами вашей команды. Таким образом, они будут одной основной ветвью проекта, и все участники должны подключить ее к своему локальному репозиторию, а затем поработать в этой локальной ветке, чтобы изменить /добавить модули и затем вернуться в основную ветвь.

Итак, Начальное состояние двух ветвей, когда вы разветвляли основной проект в своем локальном хранилище, будет таким - (A, B и C - модули, уже завершенные для проекта)

 введите описание изображения здесь

Теперь вы начали работать над новым модулем (предположим, D), и когда вы завершили модуль D, вы хотите перенести его в основную ветку, но между тем происходит то, что один из ваших товарищей по команде разработал новый модуль E , F и модифицированный C.
Итак, теперь произошло то, что в вашем локальном репозитории не хватает первоначального прогресса проекта, и, следовательно, отсылка ваших изменений в основную ветку может привести к конфликту и может вызвать сбой в работе вашего модуля D.

 введите описание изображения здесь

Чтобы избежать подобных проблем и работать параллельно с первоначальным прогрессом проекта, есть два пути:

1. Git Fetch - Это загрузит все изменения, которые были внесены в исходную /основную ветку projт. д., которых нет в вашем местном филиале. И будет ждать, пока команда Git Merge применит изменения, которые были извлечены в ваш репозиторий или филиал.

 введите описание изображения здесь

Итак, теперь вы можете внимательно следить за файлами, прежде чем объединять их с вашим хранилищем. И вы также можете изменить D, если требуется, из-за Модифицированного C.

 введите описание изображения здесь

2. Git Pull - Это обновит вашу локальную ветвь с источником /главной веткой, то есть фактически то, что она делает, это комбинация Git Fetch и Git сливаются одна за другой. Но это может привести к возникновению конфликтов, поэтому рекомендуется использовать Git Pull с чистой копией.

 введите описание изображения здесь

    
91
2018-03-03 04: 13: 05Z
  1. если бы вы могли изменить 'Main Branch' на 'Remote Repo', это был бы отличный ответ.
    2018-06-04 00: 17: 05Z

Мы просто говорим:

 
git pull == git fetch + git merge

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

Итак, в Git Gui, когда вы делаете выборку, вы должны объединить данные. Сама Fetch не будет вносить изменения в ваш локальный код. Вы можете проверить это при обновлении кода, выбрав один раз принеси и посмотри; код не изменится. Тогда вы сливаетесь ... Вы увидите измененный код.

    
82
2013-07-17 13: 35: 56Z
  1. Я бы лучше сказал git pull == git fetch + git merge:)
    2013-06-07 10: 38: 29Z
  2. Но git pull --rebase = git fetch + git rebase
    2013-07-17 07: 06: 50Z

git fetch загружает код с удаленного сервера в ваши ветви отслеживания в вашем локальном хранилище. Если ваш пульт имеет имя origin (по умолчанию), то эти ветви будут в пределах origin/, например, origin/master, origin/mybranch-123 и т. Д. Это не ваши текущие ветви, а локальные копии этих веток с сервера. . р>

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

    
79
2016-06-01 00: 59: 49Z

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

    
75
2013-03-09 20: 31: 48Z

Git Fetch

Вы загружаете изменения в свою локальную ветку от источника до получения. Fetch запрашивает у удаленного репо все коммиты, сделанные другими, но у вас нет локального репо. Загрузка этих файловфиксирует и добавляет их в локальный репозиторий.

Git Merge

Вы можете применить изменения, загруженные через fetch, используя команду merge. Merge примет коммиты, полученные из fetch, и попытается добавить их в вашу локальную ветку. Слияние сохранит историю изменений ваших локальных изменений, поэтому, когда вы поделитесь своей веткой с помощью push, Git будет знать, как другие могут объединить ваши изменения.

Git Pull

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

    
69
2017-06-16 18: 15: 10Z

Единственная разница между git pull и git fetch заключается в том, что:

git pull извлекает данные из удаленной ветви и объединяет их.

git fetch выбирает только из удаленной ветви, но не объединяет

то есть. git pull = git fetch + git merge ...

    
49
2013-06-05 15: 47: 06Z
  1. И это тоже не поможет, если git думает, что вы отстали от коммитов и можете «перемотать вперед», что в итоге закончилось rm -rf и все началось заново. Глупый мерзавец, пожалуйста, дайте мне знать, чтобы я мог вернуться к работе?
    2013-09-11 22: 01: 21Z

Git позволяет применять хронологически более старые коммиты после новых коммитов. Из-за этого процесс передачи коммитов между репозиториями делится на два этапа:

  1. Копирование новых коммитов из удаленной ветви в копию этой удаленной ветви внутри локального репо.

    (операция репо в репо) master@remote >> remote/origin/master@local

  2. Интеграция новых коммитов в локальную ветку

    (операция внутреннего репо) remote/origin/master@local >> master@local

Есть два способа выполнить шаг 2. Вы можете:

  1. Разветвите локальную ветвь после последнего общего предка и добавьте новые коммиты, параллельные коммитам, уникальным для локального репозитория, которые завершаются объединением коммитов, закрывая форк.
  2. Вставить новые коммиты после последнего общего предка и повторно применить коммиты, уникальные для локального репозитория.

В терминологии git, шаг 1 - git fetch, шаг 2 - git merge или git rebase

git pull - это git fetch и git merge

    
43
2013-11-28 17: 03: 45Z

Git получает ветку последней версии с удаленного компьютера на локальный, используя две команды:

  1. git fetch: Git собирается получить последнюю версию из удаленной в локальную, но она не объединяется автоматически.  git fetch origin master  git log -p master..origin/master  git merge origin/master

    Приведенные выше команды означают, что вы загружаете последнюю версию основной ветви из источника из удаленной в исходную главную ветку. А затем сравнивает локальную главную ветку и главную ветку происхождения. Наконец, слияние.

  2. git pull: Git собирается получить последнюю версию с пульта и объединиться с локальной.

     git pull origin master

    Указанная выше команда эквивалентна git fetch и git merge. На практике git fetch может быть более безопасным, потому что до слияния мы можем увидеть изменения и решить, следует ли слить.

35
2014-08-12 04: 00: 07Z
  

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

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

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

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

    
35
2015-07-11 10: 22: 46Z

git pull == (git fetch + git merge)

git fetch не изменяется на локальные ветви.

Если у вас уже есть локальный репозиторий с удаленной настройкой для нужного проекта, вы можете получить все ветви и теги для существующего удаленного устройства с помощью git fetch. ... Fetch не вносит никаких изменений в локальные ветви, поэтому вам нужно объединить удаленную ветку с парной локальной веткой, чтобы включить новые изменения выборки. из github

    
32
2013-09-19 22: 41: 11Z

Пытаться быть ясным и простым.

Команда git pull на самом деле является shortcut для git fetch с последующим git merge или git rebase Команда в зависимости от вашей конфигурации. Вы можете настроить свой Git-репозиторий так, чтобы git pull был выборкой, за которой следует перебазировка.

    
31
2015-07-29 18: 38: 48Z

На самом деле Git хранит копию вашего собственного кода и удаленный репозиторий.

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

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

    
31
2017-08-17 20: 51: 46Z
 
git pull = git fetch + git merge 
    
30
2015-07-12 03: 54: 52Z

Простое графическое представление для начинающих,

 введите описание изображения здесь

здесь

 
git pull  

будет извлекать код из репозитория и перезагружать его с вашим локальным ... в git pull есть возможность создания новых коммитов.

но в

git fetch

будет извлекать код из репозитория, и нам нужно перебазировать его вручную, используя git rebase

Например: я собираюсь получить от главного сервера и перебазировать его в моем локальном главном.

1) git pull (ребаз будет выполнен автоматически):

 
git pull origin master

здесь origin - это ваше удаленное хранилище master - это ваша ветка

2) git fetch (нужно перебазировать вручную):

 
git fetch origin master

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

 
git rebase origin/master

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

    
29
2017-07-12 06: 23: 41Z
  1. Хороший график, но вы, возможно, захотите объяснить, почему вы используете «rebase», когда график говорит «объединить».
2018-10-10 09: 33: 37Z
  • объединение будет представлять другой коммит ветви и генерировать новый коммит, который содержит коммиты в качестве ссылки. но rebase будет реплицировать коммиты из другой ветки, но не будет создавать новый коммит, а не копировать
    2018-10-10 11: 00: 51Z
  • источник размещен Вот