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

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

Я нашел эту хорошо написанную статью о git fetch и git pull, которую стоит прочитать: longair.net/blog/2009/04/16/git-fetch-and-merge

Marcos Oliveira 16.09.2010 10:57

Нашим альтернативным подходом стал git fetch; git reset --hard origin/master как часть нашего рабочего процесса. Он удаляет локальные изменения, держит вас в курсе последних событий, НО гарантирует, что вы не просто добавите новые изменения поверх текущих и не создадите беспорядок. Мы использовали его некоторое время, и на практике он кажется намного безопаснее. Просто не забудьте сначала добавить / зафиксировать / спрятать все незавершенные работы!

Michael Durrant 04.05.2014 18:32

Убедитесь, что вы знаете, как правильно использовать git stash. Если вы спрашиваете о «pull» и «fetch», тогда, возможно, нужно будет объяснить «stash» ...

Henry Heleine 09.12.2014 23:09

Многие люди, пришедшие из Mercurial, продолжают использовать «git pull», думая, что это эквивалент «hg pull». А это не так. Эквивалент «hg pull» в Git - «git fetch».

Serge Shultz 29.06.2015 13:15

Команда git fetch извлекает обновленный код с веткой, а также получает новые добавленные ветки в вашем локальном, команда git pull извлекает только обновленный код только текущей ветки

Kartik Patel 27.07.2017 14:43

@MichaelDurrant FWIW, эквивалент git pull --ff-only, хотя я не помню, был ли он доступен в 2014 году.

jpaugh 22.05.2018 00:16

Отметим, что git fetch не имеет корреспондента в традиционных системах управления версиями (о которых я знаю). Основная цель использования git fetch («посмотреть, что произошло удаленно») достигнута, например в SVN с помощью merge --dry-run. Это должно быть частью основного рабочего процесса, чтобы до того, как вы начнете, вы получите представление о том, какие изменения вы проводите, особенно те изменения, которые противоречили бы вашим местным изменениям.

haelix 06.09.2018 21:16

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

Honey 12.02.2019 22:30
freecodecamp.org/news/git-fetch-vs-pull/….
Shiwangini 11.07.2020 22:24

просто подумайте об этом как о веб-странице, «скачать» и «обновить»

Ernie Sender 20.11.2020 03:18
Формы c голосовым вводом в React с помощью Speechly
Формы c голосовым вводом в React с помощью Speechly
Пытались ли вы когда-нибудь заполнить веб-форму в области электронной коммерции, которая требует много кликов и выбора? Вас попросят заполнить дату,...
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно...
Flatpickr: простой модуль календаря для вашего приложения на React
Flatpickr: простой модуль календаря для вашего приложения на React
Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей....
В чем разница между Promise и Observable?
В чем разница между Promise и Observable?
Разберитесь в этом вопросе, и вы значительно повысите уровень своей компетенции.
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
Четыре эффективных способа центрирования блочных элементов в CSS
Четыре эффективных способа центрирования блочных элементов в CSS
У каждого из нас бывали случаи, когда нам нужно отцентрировать блочный элемент, но мы не знаем, как это сделать. Даже если мы реализуем какой-то...
12 433
10
2 932 652
37
Перейти к ответу Данный вопрос помечен как решенный

Ответы 37

Ответ принят как подходящий

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

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

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

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

Из документации Git для gut pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

«Git pull» - это то, что вы сделали бы, чтобы обновить свой репозиторий »<- разве обновление репозитория еще не выполнено с помощью fetch? Разве вы не имеете в виду, что он обновляет ваши локальные ветки с удаленными ветвями? К слиянию: он объединяет удаленные ветки с вашими локальными копиями этих веток, или что именно здесь сливается?

Albert 10.11.2009 15:13

@Albert: Да, это странно сформулировано. git pull всегда будет сливаться с текущая ветка. Итак, вы выбираете, какую ветку вы хотите вытащить из, и она втягивает его в текущую ветку. Ветвь из может быть локальной или удаленной; это может быть даже удаленная ветка, которая не является зарегистрированным git remote (то есть вы передаете URL-адрес в командной строке git pull).

intuited 06.06.2010 14:10

Является ли «git push» также «git fetch» ​​(в другом направлении), за которым следует «git merge»?

Ellen Spertus 17.03.2011 02:51

@espertus: Нет. При нажатии никогда не происходит слияния автоматически. Ожидается, что пользователь потянет, разрешив любые конфликты слияния локально, потом отправит обратно на удаленный.

Greg Hewgill 17.03.2011 03:41

Если я нахожусь в /home/alice/ и делаю git fetch /home/bob, какие параметры я должен передать следующему git merge?

ripper234 27.05.2011 23:38

Почему бы вам конкретно не порекомендовать что-то вроде задания cron, которое автоматически выполняет "git fetch"? На ум не приходят плохие побочные эффекты, и было бы неплохо обновить мои удаленные ветки, не задумываясь об этом.

Bryan Henry 27.10.2011 06:05

@Sbrocket: я не люблю сюрпризов, особенно при работе с моей системой управления версиями. Смена веток из-под меня (даже удаленных веток) во время работы могла дезориентировать.

Greg Hewgill 27.10.2011 22:29

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

Roman Starkov 28.09.2012 20:23

Допустим, у меня есть только ветка master. Какие ТОЧНЫЕ команды (со всеми необходимыми параметрами) должны заменить команду git pull?

Paul 25.01.2013 19:16

@espertus - FYI, если вы используете Git Extensions, вы можете выполнить автоматическое вытягивание перед нажатием, если нажатие отклонено.

Laksitha Ranasingha 31.01.2013 16:36

В качестве альтернативы вы можете обновить репозиторий git с помощью удаленного репо, выполнив git fetch, а затем git rebase origin/master

abumusamq 07.02.2013 16:16

@romkyns Я не совсем понимаю, что вы имеете в виду. Не могли бы вы объяснить, что: «Я только что получил изменение, в котором изменяется только указатель удаленной ветки, а слияние отказывается что-либо делать». средства?

viki.omega9 26.05.2013 21:15

@ dev-inside Или вобще git pull --rebase

Michael Mior 27.05.2013 01:06

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

Nikita 15.04.2014 22:51
Эта операция никогда не изменяет ни одну из ваших собственных локальных веток в refs / Heads. - что тогда делает? Я все еще плохо понимаю.
アレックス 13.06.2014 05:39

@AlexanderSupertramp: git fetch обновляет ветки удаленное отслеживание. Это ветки, перечисленные, начиная с remotes/ в git branch -a, и являются копиями ветвей в удаленном репозитории.

Greg Hewgill 13.06.2014 05:41

@GregHewgill, как он их обновляет? Похоже, вы намекаете, что он что-то подталкивает к удаленным веткам.

アレックス 13.06.2014 08:38

@AlexanderSupertramp: Я вообще этого не говорю. Ваши нормальные ветки находятся под refs/heads. Ветви удаленного отслеживания находятся под refs/remotes. Команда git fetch обновляет ваши ветки удаленного отслеживания в refs/remotes и ничего не меняет в refs/heads.

Greg Hewgill 13.06.2014 11:16

Локально я храню только локальные ветки и редактирую только их, верно? Что вы имеете в виду под ветками "обновления пультов"?

アレックス 13.06.2014 12:00

@AlexanderSupertramp: Задайте новый вопрос, если у вас возникли проблемы с пониманием терминологии Git. Раздел комментариев - не подходящее место для этого обсуждения. Спасибо.

Greg Hewgill 13.06.2014 12:02

Ключевое различие здесь - refs / remote и refs / Head. Heads относится к вашей локальной рабочей ветке, тогда как remote относится к ветке, указывающей на удаленный, с информацией с момента вашего последнего git fetch origin.

JohnMerlino 28.06.2014 20:22

@romkyns "pull на самом деле нельзя эмулировать с помощью fetch плюс merge" На самом деле, да, может. Я делаю это все время.

Ajedi32 20.08.2014 22:23

@ Ajedi32 кое-что из того, что делает pull, может быть имитировано этими двумя, да. Но не всю команду при всех возможных обстоятельствах.

Roman Starkov 22.08.2014 18:22

@romkyns Верно. Возможно, я не понял обстоятельства, упомянутые в вашем комментарии, но перемотку вперед определенно можно выполнить с помощью git merge.

Ajedi32 23.08.2014 07:09

"одновременно с обновлением других веток удаленного отслеживания" Что это означает?

user2906759 11.09.2014 16:50

@ user2906759: Git отслеживает в вашем локальном репозитории состояние всех веток на удаленном компьютере. Google "ветки удаленного отслеживания" для получения дополнительной информации об этом.

Greg Hewgill 11.09.2014 22:52

Что-то, с чем я играл. Я часто использую git fetch, чтобы получить изменения. Если вы затем выполните команду git pull, то окажется, что он снова подключается к сети. Вместо этого ПОСЛЕ выборки я запустил 'git merge @ {u}', который, как мне кажется, сливается в заголовке настроенной ветки отслеживания без повторного подключения к сети. Кажется быстрее. Предупреждение - я все еще экспериментирую!

Damien Sawyer 16.12.2014 23:53

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

Didier A. 05.01.2015 19:44

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

Doctor Blue 22.01.2015 17:16

Теперь я понимаю, почему pull из master в текущую ветку не обновляет ветку, даже если в master слиты новые локальные коммиты. Это потому, что merge в pull объединяется с FETCH_HEAD и полностью игнорирует мой локальный master! Я бы хотел, чтобы это важное различие было лучше подчеркнуто во всех руководствах, в которых упоминается pull и утверждается, что он почти такой же, как fetch + merge. «Почти» действительно важно, если вы работаете с pull и надеетесь сделать все-в-одном - выборка + слияние с удаленного И слияние с локального. Сюрприз - pull не сливается из локальной ветки!

JustAMartin 21.10.2015 22:53

Означает ли «обновление веток удаленного отслеживания», что все ветки в репозитории теперь доступны в вашем локальном репозитории?

Jwan622 25.03.2016 19:16

@ Jwan622: Да, это правильно. git branch -a перечислит их все.

Greg Hewgill 26.03.2016 04:06

Я видел такой же ответ на Quora :) Вот: quora.com/Whats-the-difference-between-git-pulland-git-fetch‌.

Pragyaditya Das 02.04.2016 08:27

Если вы работаете с плохим интернет-соединением, неплохо было бы запустить задание cron для git fetch.

noɥʇʎԀʎzɐɹƆ 11.10.2016 01:35

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

Josef.B 15.12.2016 05:54

Git fetch означает, что вы получаете новый репозиторий из git, созданный кем-то. Git pull означает, что вы получаете новый код из git или какого-то репозитория, который кто-то отправил.

Chirag Prajapati 20.11.2017 21:27

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

Hasib Kamal 19.03.2018 08:10

@GregHewgill Если fetch только загружает изменения из удаленной ветки и обновляет данные репозитория, но оставляет локальную ветку неизменной, какой смысл извлекать, если рабочий каталог не будет отображать / отражать изменения? Первоначально мой вопрос заключался в том, как я могу увидеть изменения, внесенные кем-то другим, а затем решить, хочу ли я объединить их в свой рабочий каталог (т.е. поэкспериментировать с изменениями других людей, чтобы убедиться, что это не нарушит мою работу), но я все еще запутался, как это сделать. Стоит ли просто потянуть и поэкспериментировать / исследовать, а если возникнут проблемы, сделать полный сброс?

user285372 09.06.2018 20:02

@Joshua: После загрузки удаленные ветки становятся доступны с такими именами, как origin/master (вместо master, который принадлежит вам). Вы можете просмотреть эти ветки локально, чтобы увидеть, что изменилось, перед фактическим слиянием.

Greg Hewgill 10.06.2018 02:18

Текущее (см. Отметку даты и времени) расширение Visual Studio Code C / C++ отправляет всплывающее уведомление с просьбой выполнять периодические команды git fetch.

bscout11 05.02.2020 08:33
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.

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

Очень интересно, но я не вижу случая, когда вам нужен «просто код». Что происходит с вашим кодом при загрузке? Это стерто? Что происходит с удаленными изменениями? Как он попадает в ваше репо без стирания кода, если вы не объединяетесь?

e-satis 27.03.2010 19:21

@ e-satis: удаленная ветка также хранится локально на вашем компьютере. Поэтому, когда вы выполняете git fetch, он извлекает изменения из репозитория и обновляет вашу локальную удаленную ветку. Это не влияет на вашу локальную ветвь, которая отслеживает локальную удаленную ветку, поэтому не влияет на вашу рабочую копию. Теперь, когда вы сделаете merge, он объединит полученные изменения с вашей локальной веткой.

jeffreyveon 31.10.2011 08:23

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

Lorenzo Gatti 19.09.2013 14:25

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

git fetch
git diff ...origin

См .: https://git-scm.com/docs/git-diff относительно синтаксиса двойной и тройной точки в команде diff

почему не git diff ..origin?

Erik Kaplun 13.02.2012 03:47

git diff origin и git diff ..origin, похоже, работают, но не этот странный ... материал

Marc 08.01.2013 23:32

@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#_descript‌ ion), который отличается от git diff origin; git diff ...origin концептуально представляет собой изменения, внесенные в origin, поскольку текущая ветвь разветвлена ​​от origin, тогда как git diff origin включает также обратные изменения, сделанные в текущей ветке, поскольку она разветвлена ​​от origin.

Max Nanasy 01.08.2013 23:34

ни одна из команд .. не сработала у меня (в Windows), но git diff origin/master работает, как указано ниже

Brian Burns 20.02.2014 13:07

то же самое здесь, используя git 2.0.0 на OSX. Ни одна из этих команд не сработала. Они устарели?

K.-Michael Aye 26.06.2014 06:39

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

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

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

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

Justin Ohms 01.09.2012 00:02

Короткий и простой ответ заключается в том, что 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:

This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.

@JustinOhms Если git pull --rebase не подходит в данной ситуации, правильно ли, если это делается в два этапа? Если это правильно, то какая дополнительная польза от того, чтобы сделать это в два этапа?

Kaz 24.05.2013 01:56

@Kaz - потому что перебазирование не автоматическое. Получение изменений в первую очередь позволяет вам принять решение. Это не решает проблему с измененной историей, которую вы уже отправили. Это позволит вам увидеть, безопасно ли перебазировать изменения, которые вы еще не отправили.

Justin Ohms 25.05.2013 01:11

@JustinOhms Как бы вы решили, безопасно ли перебазировать изменения? Я бы просто попробовал git rebase и отступил бы, если бы возник беспорядок, и в этом случае я мог бы также сделать git pull --rebase. Но, может быть, у вас есть другой способ?

Kaz 25.05.2013 10:14

@KaZ gitk позволяет визуально увидеть структуру ветвей. Он покажет вам положение вашей локальной головы, пультов дистанционного управления и структур ветвей по отношению к тому, что вы получили. Таким образом вы можете быть уверены, что не выполняете перенастройку извлеченных изменений, основанных на предке, предшествующем тому, что вы уже отправили на свои удаленные устройства.

Justin Ohms 28.05.2013 23:18

Используйте rebase, когда вы работаете в локальной ветке, которая еще не отправлена. Если вы работаете с веткой, которая существует на пульте дистанционного управления, rebase может вызвать некоторые неприятные проблемы, поэтому вам следует предпочесть обычный merge.

Justus Romijn 01.12.2014 11:39

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

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

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

Согласен, отличный комментарий. Вот почему я ненавижу git pull. Когда когда-нибудь будет иметь смысл позволить инструменту редактирования вносить изменения в код за вас? И разве это не то, что происходит при слиянии двух файлов? Что, если эти два редактирования физически разделены в файле, но ЛОГИЧЕСКИ расходятся?

Lee Dixon 13.05.2013 22:44

Я не уверен, правильно ли я это понимаю. Дайте мне знать, если я прав: допустим, у меня есть две ветки, основная и тестовая. test - это ветка, над которой я работаю, чтобы что-то поэкспериментировать. Если я сделаю git fetch, он обновит master с целевой веткой. Если я сделаю git pull, он попытается обновить тест с помощью целевой ветки. Это правильно? Если нет, думаю, я не понимаю, что означает «локальный репозиторий» - я предположил, что это означает мой локальный мастер.

elexhobby 05.06.2013 23:15

Коротко говоря, @elexhobby: git fetch обновляет только ваш каталог .git/ (также известный как локальный репозиторий) и ничего за пределами .git/ (также известный как рабочее дерево). Он не меняет ваши локальные ветки и не касается master. Но это касается remotes/origin/master (см. git branch -avv). Если у вас больше пультов, попробуйте git remote update. Это git fetch для всех пультов в одной команде.

Tino 17.07.2013 10:48

@Tino, ваш действительно самый важный момент. Люди могут не знать, что «удаленные» ветки на самом деле хранятся в .git/refs/remotes/origin/ как набор хэшей.

Chris 13.09.2013 01:49

Как только я понял, что все идет «хотя», отслеживая ветки, я наконец действительно понял git. Без этого знания это просто «волшебство».

Michael Durrant 19.09.2013 23:55
Когда вы выполняете выборку, Git собирает все коммиты из целевой ветки, которых нет в вашей текущей ветке, и сохраняет их в вашем локальном репозитории. - как мне увидеть, что было принесено с пульта, и как мне слить это с моими локальными ветвями?
アレックス 13.06.2014 05:40

@Tino Чего я до сих пор не понимаю ... в чем смысл? Зачем использовать выборку, если она обновляет только .git? Какова предполагаемая выгода и что мне делать после этого?

BadHorsie 23.03.2016 15:19

@BadHorsie git fetch скачивает ревизии.

Tino 30.03.2016 16:40
git pull --ff-only обычно то, что мне нужно. Делает бессмысленные вещи автоматически, спрашивает, прежде чем усложнять историю.
Nick T 19.12.2017 01:05

Я считаю этот ответ отличным. Для меня хорошей комбинацией для достижения цели с помощью git fetch является ввод «git status», и вы увидите что-то вроде: «ничего не нужно фиксировать, рабочее дерево очищено», затем вы можете набрать «git fetch», а затем набрать «git status» и вы увидите, что ваша ветка «опережает удаленный репозиторий» или что-то в этом роде. Если вы наберете «git pull», вы объедините ветку, но с помощью «git fetch» ​​вы только осознаете свой локальный репозиторий, если вы впереди или позади с некоторыми коммитами.

eduardo92 12.06.2018 16:39
git pull означает «получить удаленные ветки и объединить мою текущую ветку с любыми случайными коммитами, сделанными в удаленных ветвях». В этом почти нет никакого смысла. git fetch, за которым следует gitk или git log --oneline --graph --decorate --date-order, и, возможно, git rebase или git merge имеют гораздо больший смысл.
Mikko Rantalainen 25.10.2018 13:50

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

Thagomizer 24.09.2019 01:11

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

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

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

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

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

origin / master - это локальная ветвь, которая является КОПИЕЙ мастера в источнике. При загрузке вы обновляете local: / origin / master. Как только вы действительно поймете, что все в git является ветвью, это имеет большой смысл и является очень мощным способом поддержки различных наборов изменений, быстрого создания локальных ветвей, слияния и перебазирования и, как правило, получения большой выгоды от дешевого ветвления. модель.

cam8001 28.05.2013 20:00

Все еще сбивает с толку. Я думал, что git fetch должен буквально загружать изменения из удаленного репо в ваше локальное репо, но НЕ фиксировать их - т.е. они все равно должны быть добавлены / зафиксированы в вашем локальном репо.

krb686 26.02.2015 17:57

fetch извлекает только из удаленного / источника (github) в ваш локальный источник. Но он не объединяет его с вашими фактическими рабочими файлами. если вы сделаете вытягивание, он будет извлечен и объединен с вашими текущими рабочими файлами

Gerardo 26.02.2015 22:45

что, если вас не устраивают изменения после git fetch? что делать дальше?

Ahmad 29.12.2020 02:42

Я тоже боролся с этим. Фактически, я попал сюда с поиском в 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+               -
---------------------     -----------------------     -----------------------

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

Не так сложно читать: поля представляют собой статус репо, который в каждой строке изменяется во времени слева направо после операции, о которой сообщается в строке 2 поля. Ярлыки R0n - это теги в git, а тег со знаком + еще не заполнен. Sanbox используется для вашей рабочей папки, которая отличается от папки репо, где хранятся коммиты.

user1708042 30.08.2017 10:57

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

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

git pull == git fetch + git merge

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

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

Скорее git pull == git fetch + git merge :)

melvynkim 07.06.2013 14:38

Но git pull --rebase = git fetch + git rebase

Tino 17.07.2013 11:06

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

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

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

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

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

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

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

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

Технически локальный и удаленный репозитории действительно одно и то же. В Git репозиторий - это DAG коммитов, указывающих на их родителей. Технически ветки - это не что иное, как значимые имена коммитов. Единственная разница между локальными и удаленными ветвями состоит в том, что удаленные имеют префикс remoteName/. Git с нуля - очень хорошее чтение. Как только вы поймете, как работает Git - а на самом деле это красиво просто - все обретет смысл.

Emil Lundberg 14.08.2013 13:51

Большое спасибо за объяснение. До сих пор я действительно не понимал, что Git был разработан так, что вам не нужно было иметь центральный репозиторий. Все всегда говорят «DVCS», когда описывают Git, но для меня, как для относительно нового программиста, это ничего не значит. Я никогда не видимый CVCS, и я также никогда не работал с центральным удаленным репозиторием при сотрудничестве с другими (например, Github), поэтому до сих пор я еще не понял, что сделало Git особенным.

Brian Peterson 15.08.2013 06:17

Итак, исходя из этого, почему это НЕ хорошая идея использовать git-fetch с заданием cron? Всегда хранить копию пульта ДУ, с которым вы работаете, на своем локальном компьютере кажется хорошей идеей. На самом деле, мне хочется написать сценарий, который проверяет, обновлял ли я свой пульт за последние 24 часа, и связать его с крючком udev для подключения к Интернету.

Brian Peterson 15.08.2013 06:23

Глупый вопрос - эти «три копии» поддерживаются Git, а я их никогда не видел? или я скачал одну копию и создал две ветки?

Nabheet 14.09.2013 16:47

@Nabheet: я считаю, что дополнительные копии хранятся не как обычные файлы в вашей файловой системе, а как альтернативные истории (наборы изменений) внутри ваших файлов репозитория git.

Keen 17.09.2013 06:55

Одна из причин, по которой НЕ является хорошей идеей иметь задание cron: часто, когда я работаю либо над новым заявлением, либо над обновлениями ветки, мне нравится видеть, как вносятся изменения. Если изменения не будут внесены во время выборки, я буду более уверенно спрашивать своего товарища-программиста: «Эй, ты нажал?». Я также понимаю, сколько «оттока» в репозитории с момента последней загрузки. Это также помогает мне понять количество и скорость изменений, которые в настоящее время вносятся в этот репозиторий.

Michael Durrant 23.07.2014 15:47

@Nabheet Дело в том, что Git ориентирован на контент. Он хранит данные только один раз и указывает на них несколько раз. Вот почему в Git даже несколько коммитов поверх оригинала не сильно влияют на размер репо, поскольку большинство объектов одинаковы.

cst1992 05.11.2016 12:43

это наиболее проясняющий ответ. Я хотел бы, чтобы это было просто, но я бы просто добавил в скобки некоторые технические имена, такие как Head, index и рабочее дерево / каталог, вместе с простыми объяснениями / аналогиями (например, где я храню свой собственный код)

Luis Martins 24.02.2018 05:52

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

MikeD 14.03.2018 21:52

@MikeD >> Git был разработан для поддержки более распределенной модели без необходимости в центральном репозитории.. Читать - чтобы поддержать людей еще совершая часто во время длительных перелетов (во время которых нет интернета).

haelix 06.09.2018 21:23

Этот ответ следует объединить со следующим ответом Contango, содержащим изображение отношений. Затем, добавленный к верхнему ответу Грегом Хьюджиллом, он дает самое краткое и ясное объяснение последствий pull vs fetch. Хотя, к счастью, пока что порядок ответов таков.

GG2 01.10.2018 21:06

Вкратце

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/

Мне кажется, что если кто-то просто хочет, чтобы местный код отражал «подсказку», им следует использовать git clone. Я заключил совет в кавычки, так как предполагаю, что это будет означать, какой бы ни был мастер и что кто-то может "скачать как zip" с github.com.

Chris K 12.09.2013 12:27

что, если вас не устраивают изменения после git fetch? что делать дальше?

Kugutsumen 24.03.2015 09:06

Ваш абзац о перебазировании был именно тем, что я искал. Вся идея об обнулении всего, обновлении с удаленного, затем воспроизведение ваших изменений поверх предыдущих коммитов, которое произошло, пока вы работали. Идеальное объяснение, если оно правильное. ;)

coblr 03.03.2016 03:01

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

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

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

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

И ничто не поможет, если git думает, что вы отстаете из-за коммитов и можете "перемотать вперед", что в итоге привело к тому, что rm -rf все это сделал и начал заново. Глупый мерзавец, дай мне получить текущую информацию, чтобы я мог вернуться к работе?

Chris K 12.09.2013 02:01

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

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

git pull == (git fetch + git merge)

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

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

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.

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

                                         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.

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

  • Представление (пролистайте все коммиты и сообщения, не пытаясь протолкнуть его по сети)
  • Обратная связь о состоянии вашего локального репо (например, я использую Atlassian SourceTree, который дает мне лампочку, указывающую, совершаю ли я вперед или назад по сравнению с источником. Эту информацию можно обновить с помощью GIT FETCH).

Разве git pull не выполняет также слияние, то есть доходит до рабочей копии?

Kamiel Wanrooij 24.03.2014 21:28

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

Justus Romijn 25.03.2014 11:50

@JustusRomijn Разве при вытягивании не обновляется и локальный репозиторий? Разве между звездочкой исходной и рабочей копии не должно быть звездочки?

user764754 08.01.2015 12:34

@ user764754 Когда вы вытягиваете, ваша рабочая копия получает изменения (также могут быть некоторые конфликты, которые вам может потребоваться разрешить). Вам все равно нужно зафиксировать его в локальном репозитории.

Justus Romijn 12.01.2015 10:17

@JustusRomijn: Спасибо за иллюстрацию. Было бы здорово, если бы вы могли сделать диаграмму более полной, проиллюстрировав эффекты таких операций, как сброс, выбор вишни на состояниях репозитория.

jith912 17.01.2015 15:42

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

Justus Romijn 19.01.2015 11:11

@ jith912 в одном из ответов дана эта ссылка: ndpsoftware.com/git-cheatsheet.html

Justus Romijn 13.02.2015 13:35

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

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

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

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

    git pull origin master

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

enter image description here

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

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

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

M. Luisa Carrión 04.10.2016 03:41

Этот ответ должен быть наверху

Trect 26.10.2019 09:12

«Картинка стоит 1000 слов». Эта веб-страница - отличный ресурс для всех, кому нужно простое графическое описание различных рабочих процессов Git. Спасибо, что разместили эту ссылку.

Jim Fischer 30.08.2020 06:59

What is the difference between git pull and git fetch?

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

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

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

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

enter image description here

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

Обновленный образ с git clone и git merge был бы очень кстати!

MEMark 08.09.2015 17:23

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

JustAMartin 21.10.2015 22:57

Одна картинка стоит тысячи слов! Готово ли где-нибудь обновленное изображение с потоком данных клонирования и слияния? Любой другой поток данных, кроме того, что уже на диаграмме?

shikhanshu 25.11.2015 03:27

@Contango, пожалуйста, добавьте клон и слейте. Было бы полезно для новичков вроде меня.

rents 15.01.2016 19:02

Есть две диаграммы, показывающие клонирование и слияние в других ответах (ниже) th3sly и thedarkpassenger.

intotecho 12.08.2016 03:42

Перебазирование происходит из удаленного репозитория? Я думаю, что rebase - это операция над локальным репозиторием: git-scm.com/docs/git-rebase

Edward Ross 26.09.2016 12:55

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

MikeD 20.06.2017 23:02

Это «тянуть или перебазировать» неверно. Потому что, когда вы вытягиваете, вы фактически выполняете выборку, а затем слияние. При загрузке вы получаете новые изменения из удаленной ветки в локальную, но, что важно, они еще не добавлены в ваши файлы. Как будто изменения где-то припаркованы. Изменения будут добавлены к вашим файлам, если вы их объедините. Затем ваши изменения «расплавляются» в ваших файлах и фиксируются.

AndaluZ 13.09.2017 12:36

Согласитесь с @EdwardRoss, @MikeD и @AndaluZ: Rebase - это локальное репо для операции рабочей копии. IMEHO, я бы изменил это так, чтобы Pull был удаленным репо как для локального репо, так и для рабочей копии; Fetch - это удаленное репо в локальное репо, а Merge и Rebase - это локальное репо для рабочей копии. Отчасти путаница возникает из-за того, что git rebase похож на git checkout, это одна команда, которая имеет несколько разных эффектов. например git checkout может иметь эффект либо svn switch, либо svn revert (и других) в зависимости от того, как он используется.

dgnuff 27.03.2018 23:10

Все еще жду обновленное изображение спустя 4 года :)

JOATMON 10.10.2019 21:50
git pull = git fetch + git merge 

gut pull

Он выполняет две функции с помощью одной команды.

Он извлекает все изменения, внесенные в удаленную ветку, а затем объединяет эти изменения в вашу локальную ветку. Вы также можете изменить поведение pull, передав --rebase. Разницу между слиянием и перебазированием можно прочитать здесь

git fetch

Git fetch выполняет только половину работы git pull. Он просто переносит удаленные изменения в ваше локальное репо, но не применяет их к вашим веткам. Вы должны явно применить эти изменения. Это можно сделать следующим образом:

git fetch
git rebase origin/master

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

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

Фактически Git поддерживает копию вашего собственного кода и удаленный репозиторий.

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

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

Следует помнить о природе git. У вас есть пульты и локальные ветки (не обязательно одинаковые). По сравнению с другими системами управления версиями это может немного озадачить.

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

git fetch будет работать с удаленной веткой и обновлять вашу информацию.

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

Ваша работа в местном филиале по-прежнему не нарушена. Чтобы внести изменения в вашу локальную ветку, вам необходимо объединить / переустановить изменения из удаленной ветки.

git pull выполняет именно эти два шага (т.е. --rebase для перебазирования вместо слияния)

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

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

Бонус:

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

git pull --rebase

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

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

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

Хороший совет, хотя стоит упомянуть новым пользователям git, что rebase изменяет хэши коммитов (я обнаружил, что это удивительно из-за subversion).

AlexMA 20.09.2016 15:57

Вы можете объяснить, в чем разница между git pull и git pull --rebase?

Shaiju T 17.01.2018 10:02

См. Строгое предупреждение об этом методе в ответе выше: stackoverflow.com/a/6011169/241244

user241244 24.10.2018 11:00

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

enter image description here

Думаю, картина должна показать, что это влияет и на локальное репо. То есть Git pull - это комбинация воздействия на локальное репо и рабочую копию. Прямо сейчас кажется, что это влияет только на рабочую копию.

nonopolarity 14.02.2016 21:51

@ 太極 者 無極 而 生 Согласен - это изображение вводит в заблуждение, потому что из-за него создается впечатление, что git pull - это пропуская выборка, что, конечно, неточно.

forresthopkinsa 20.08.2016 18:33

в чем разница между «локальным репозиторием» и «рабочей копией»? Разве они не оба локальны на компьютере?

theITvideos 16.11.2017 06:12

В чем тогда смысл git fetch? как узнать какая разница между локальным репозиторием и рабочей копией?

Vikash 13.03.2019 09:56

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

Vikash 13.03.2019 09:59

у этого поста много положительных отзывов, но картина вводит в заблуждение. Pull пропускает локальное репо, что неверно. codeahoy.com/img/git-pull-vs-fetch.png

goblinjuice 02.02.2020 17:35

Git Fetch

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

Git Merge

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

Git Pull

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

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

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

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

enter image description here

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

enter image description here

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

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

enter image description here

Итак, теперь вы можете внимательно следить за файлами, прежде чем объединять их в свой репозиторий. И вы также можете изменить D, если это необходимо, из-за Modified C.

enter image description here

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

enter image description here

если бы вы могли изменить «Основную ветвь» на «Удаленное репо», это был бы отличный ответ.

Fuevo 04.06.2018 03:17

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

git fetch

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

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-config1).

When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured 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.


gut pull

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

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-fetch1. can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (e.g., 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.


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

git pull and git fetch

Если вам нравится изображение, взгляните на шпаргалку по git, которая аналогична всем командам git ... ndpsoftware.com/git-cheatsheet.html

Tom 20.05.2018 19:42

Разве клонирование не влияет на локальный репозиторий (копирование всей истории с удаленного)?

Tom Loredo 04.07.2018 07:38

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

enter image description here

здесь,

git pull  

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

но в ,

git fetch

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

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

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

git pull origin master

здесь источник - это ваше удаленное репо мастер - это ваша ветка

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

git fetch origin master

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

git rebase origin/master

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

Хороший график, но вы можете объяснить, почему вы используете «rebase», когда на графике написано «merge».

Guntram Blohm 10.10.2018 12:33

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

Mohideen bin Mohammed 10.10.2018 14:00

Git Fetch

Помогает вам узнавать о последних обновлениях с git repository. Допустим, вы работаете в команде, использующей GitFlow, где команда работает над несколькими branches (функциями). С git fetch --allcommand вы можете узнать обо всех новых branches в repository.

В основном git fetch используется с git reset. Например, вы хотите вернуть все локальные изменения в текущее состояние репозитория.

git fetch --all // get known about latest updates
git reset --hard origin/[branch] // revert to current branch state

Git pull

Эта команда обновляет ваш branch до текущего состояния repositorybranch. Продолжим с GitFlow. branches с множеством функций был веткой merged в develop, и когда вы хотите разработать новые функции для проекта, вы должны перейти к разработке branch и выполнить git pull, чтобы получить текущее состояние developbranch.

Documentation for GitFlow https://gist.github.com/peterdeweese/4251497

Все ветки хранятся в .git/refs

Все локальные филиалы хранятся в .git/refs/heads

Все удаленные ветки хранятся в .git/refs/remotes

The git fetch command downloads commits, files, and refs from a remote repository into your local repo. Fetching is what you do when you want to see what everybody else has been working on.

Итак, когда вы делаете git fetch, все файлы, коммиты и ссылки загружаются в

этот каталог .git/refs/remotes

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

Кроме того, вы можете объединить их, если хотите.

git pull just downloads these changes and also merges them to the current branch.

Пример

Если вы хотите увидеть работу удаленной ветки dev/jd/feature/auth, вам просто нужно сделать

git fetch origin dev/jd/feature/auth

чтобы увидеть изменения или ход работы,

git checkout dev/jd/feature/auth

Но, если вы также хотите получить и объединить их в текущей ветке, сделайте,

git pull origin dev/jd/feature/auth

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

Простое объяснение:

git fetch

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

git pull

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

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

Jonathan Leffler 19.05.2020 08:13

Этот рисунок может помочь. git pull по существу эквивалентен git fetch, затем git merge

This graphic could be of help. git pull is essentially equivalent to git fetch then git merge

git merge влияет не только на вашу рабочую копию ...

masterxilo 15.12.2020 22:34

Репозиторий git содержит неизменяемые блоки данных и несколько изменяемых указателей / ссылок / имен (мы называем их ветвями, HEADS) для удобства использования (теоретически git может быть хранилищем только для добавления, доступ к которому осуществляется только хешами коммитов).

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

git fetch загружает на ваш компьютер самые свежие BLOB-объекты и удаленные изменяемые файлы.

Он не изменяет ваши изменяемые файлы и не создает никаких блобов, которые ранее где-то не существовали.

git pull - это git fetch, затем git merge. git merge создает новые капли, которых никогда раньше не было в удаленном репозитории, и обновляет ваши изменяемые файлы (ваши ссылки).

Другие вопросы по теме