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

avatar
pupeno
15 ноября 2008 в 09:51
2995940
39
12684

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

Источник
Marcos Oliveira
16 сентября 2010 в 06:57
388

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

Michael Durrant
4 мая 2014 в 14:32
58

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

Henry Heleine
9 декабря 2014 в 20:09
32

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

Serge Shultz
29 июня 2015 в 10:15
43

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

Ответы (39)

avatar
Greg Hewgill
15 ноября 2008 в 09:52
10598

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

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

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

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

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

Albert
10 ноября 2009 в 12:13
351

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

intuited
6 июня 2010 в 10:10
206

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

Greg Hewgill
17 марта 2011 в 00:41
136

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

ripper234
27 мая 2011 в 19:38
36

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

Roman Starkov
28 сентября 2012 в 16:23
114

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

avatar
MuhammadAliDEV
18 января 2022 в 09:17
2

По определению:

Git Fetch:

Git fetch — это команда, позволяющая загружать объекты из другого репозитория.

Git Pull:

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

Ключевые отличия

Когда следует использовать Git Fetch?

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

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

Команда:

$ git fetch origin

Когда следует использовать Git Pull?

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

Команда:

$ git pull origin master

Факт:

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

Зачем Вам нужны эти команды?

например, в ваш удаленный репозиторий недавно были внесены изменения, и вы хотите включить их в свою локальную копию. У вас есть несколько вариантов здесь; два наиболее распространенных действия для получения изменений с вашего пульта — это Git pull и Git fetch.

Вопросы для рассмотрения:

Получить:

  • Его основная функция — получение содержимого.
  • Он имеет только синтаксис командной строки.

Потяните:

  • Его основная функция — это сочетание выборки и объединения контента.
  • Он имеет синтаксис командной строки, а также запрос на вытягивание для публикации изменений.

Мое мнение:

Git Pull лучше, чем git fetch, поскольку выполняет функции двух команд. Однако Git Fetch считается более безопасным по сравнению с Git Pull.

Jonathan Leffler
20 января 2022 в 16:32
0

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

avatar
masterxilo
15 декабря 2020 в 19:32
0

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

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

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

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

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

avatar
Piaget Hadzizi
19 ноября 2020 в 09:20
4

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

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

masterxilo
15 декабря 2020 в 19:34
0

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

avatar
Akash Yellappa
13 мая 2020 в 16:32
8

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

git fetch

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

git pull

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

avatar
Sujeet Agrahari
7 ноября 2019 в 06:54
17

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

Все местные отделения хранятся в .git/refs/heads

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

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

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

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

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

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

git pull просто загружает эти изменения и объединяет их с текущий филиал.

Пример

Если вы хотите увидеть работу удаленной ветки 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 получит ветку и также объединится с текущей веткой.

avatar
Honey
12 февраля 2019 в 19:25
78

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

В плане вы можете внести изменения в локальное рабочее пространство, а затем объединить его с тем, что вы получили ранее, а затем разрешить потенциальные конфликты слияния без подключения к Интернету. И если кто-то не внес новых изменений в удаленный репозиторий, тогда, когда вы прибудете в пункт назначения, вы сделаете git push origin <branch> и пойдете за кофе.


Из этого замечательного учебника Atlassian:

Команда git fetch загружает коммиты, файлы и ссылки из удаленный репозиторий в ваш локальный репозиторий.

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

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


С git pull:

  • Вы не получаете никакой изоляции.
  • Его не нужно извлекать явно. Потому что он неявно выполняет git merge.
  • Шаг слияния повлияет на вашу локальную разработку и может вызвать конфликты
  • Это НЕ безопасно. Это агрессивно.
  • В отличие от git fetch, где он влияет только на ваш .git/refs/remotes, git pull повлияет на ваш .git/refs/remotes и .git/refs/heads/

Хммм ... так что, если я не обновляю рабочую копию с помощью git fetch, то где мне вносить изменения? Где Git fetch хранит новые коммиты?

Отличный вопрос. Прежде всего, heads или remotes не хранят новые коммиты. У них просто указателей на коммиты. Итак, с помощью git fetch вы загружаете последние объекты git (blob, tree, commits. Чтобы полностью понять объекты, посмотрите это видео на внутреннем устройстве git), но обновите только свой remotes указатель, указывающий на последнюю фиксацию этой ветки. Он по-прежнему изолирован от вашей рабочей копии, потому что указатель вашей ветки в каталоге heads не обновился. Он будет обновляться только после merge / pull. Но опять же где? Давай выясним.

В каталоге вашего проекта (т.е. где вы выполняете свои команды git) выполните:

  1. ls. Это покажет файлы и каталоги. Я знаю, ничего крутого.

  2. Теперь сделайте ls -a. Это покажет точечные файлы, то есть файлы, начинающиеся с .. После этого вы сможете увидеть каталог с именем: .git.

  3. Сделайте cd .git. Очевидно, это изменит ваш каталог.

  4. А теперь самое интересное. сделать ls. Вы увидите список каталогов. Мы ищем refs. Сделайте cd refs.

  5. Интересно посмотреть, что находится внутри всех каталогов, но давайте сосредоточимся на двух из них. heads и remotes. Также используйте cd, чтобы проверить их внутри.

  6. Любое действие git fetch обновит указатель в каталоге /.git/refs/remotes. Он ничего не обновит в каталоге /.git/refs/heads.

  7. Любой git pull сначала выполнит git fetch, обновит элементы в каталоге /.git/refs/remotes, затем объединится с вашим локальным, а затем изменит заголовок внутри каталога <7902620147147902620.


Очень хороший ответ на эту тему также можно найти в Где находится 'git fetch'? .

Кроме того, поищите «Обозначение косой черты» в сообщении Правила именования веток Git. Это поможет вам лучше понять, как Git размещает вещи в разных каталогах.


Чтобы увидеть фактическую разницу

Просто сделайте:

git fetch origin master
git checkout master

Если удаленный мастер был обновлен, вы получите такое сообщение:

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Если бы вы не fetch и только что сделали git checkout master, то ваш локальный git не узнает, что добавлены 2 коммита. И было бы просто сказано:

Already on 'master'
Your branch is up to date with 'origin/master'.

Но это устарело и неверно. Это потому, что git предоставит вам обратную связь исключительно на основе того, что он знает. Он не обращает внимания на новые коммиты, которые еще не сняты ...


Есть ли способ увидеть новые изменения, внесенные удаленно, при локальной работе в ветке?

Некоторые IDE (например, Xcode) очень умны и используют результат git fetch и могут аннотировать строки кода, которые были изменены в удаленной ветви вашей текущей рабочей ветви. Если эта строка была изменена как локальными изменениями, так и удаленной ветвью, она помечается красным цветом. Это не конфликт слияния. Это потенциальный конфликт слияния. Это заголовок, который вы можете использовать для разрешения будущего конфликта слияния, прежде чем выполнять git pull из удаленной ветки.

enter image description here


Подсказка:

Если вы выбрали удаленную ветку, например сделал:

git fetch origin feature/123

Затем это войдет в ваш каталог пультов дистанционного управления. Он по-прежнему недоступен в вашем локальном каталоге. Однако это упрощает оформление заказа на удаленную ветку с помощью DWIM (делайте то, что я имею в виду):

git checkout feature/123

вам больше не нужно:

git checkout -b feature/123 origin/feature/123

Подробнее об этом читайте здесь

avatar
Andrei Todorut
22 декабря 2017 в 20:36
5

Git Fetch

Помогает узнавать о последних обновлениях с сайта git repository. Допустим, вы работаете в команде, используя GitFlow, где команда работает над несколькими branches (функциями). С помощью git fetch --all command вы можете узнавать обо всех новых 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 с текущим состоянием repository branch. Продолжим с GitFlow. Множественная функция branches была от merged до ветви develop, и когда вы хотите разработать новые функции для проекта, вы должны перейти к разработке branch и выполнить git pull, чтобы получить текущее состояние develop branch

Документация для GitFlow https://gist.github.com/peterdeweese/4251497

avatar
Mohideen bin Mohammed
12 июля 2017 в 06:23
35

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

enter image description here

здесь,

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

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

avatar
Alireza
21 июня 2017 в 09:48
167

ОК , вот некоторая информация о 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 and git fetch

avatar
Aman Tiwari
7 февраля 2017 в 14:15
113

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

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

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

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- Это обновит вашу локальную ветвь исходной / основной ветвью, то есть на самом деле то, что он делает, представляет собой комбинацию Git Fetch и Git слияния одного за другим. Но это может вызвать конфликты, поэтому рекомендуется использовать Git Pull с чистой копией.

enter image description here

avatar
Pinkesh Sharma
13 июля 2016 в 21:23
75

Git Fetch

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

Git Merge

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

Git Pull

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

avatar
thedarkpassenger
25 января 2016 в 17:28
243

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

enter image description here

nonopolarity
14 февраля 2016 в 18:51
21

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

avatar
Sazzad Hissain Khan
23 декабря 2015 в 15:31
134

Бонус:

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

git pull --rebase

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

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

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

avatar
g24l
25 сентября 2015 в 09:46
23

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

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

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

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

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

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

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

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

avatar
Pokemon
13 сентября 2015 в 18:48
34

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

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

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

avatar
Montells
29 июля 2015 в 18:38
35

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

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

avatar
Animesh Sharma
12 июля 2015 в 05:39
25

git pull

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

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

git fetch

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

git fetch
git rebase origin/master
avatar
Saqib R.
12 июля 2015 в 03:54
31
git pull = git fetch + git merge 
avatar
Contango
9 июня 2015 в 13:30
974

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

enter image description here

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

MEMark
8 сентября 2015 в 14:23
173

Было бы очень полезно обновить изображение с git clone и git merge!

JustAMartin
21 октября 2015 в 19:57
21

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

shikhanshu
25 ноября 2015 в 00:27
12

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

avatar
Donal
19 мая 2015 в 11:57
37

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

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

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

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

avatar
th3sly
6 февраля 2015 в 11:48
147

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
4 октября 2016 в 00:41
20

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

avatar
Marcus Thornton
12 августа 2014 в 04:00
37

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 может быть более безопасным, потому что перед слиянием мы можем увидеть изменения и решить, следует ли выполнять слияние.

avatar
Justus Romijn
19 февраля 2014 в 21:18
123

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

                                         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).
avatar
Pawel Furmaniak
28 ноября 2013 в 17:03
44

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

avatar
Iggy
19 сентября 2013 в 22:41
35

git pull == (git fetch + git merge)

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

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

avatar
Michael Durrant
19 сентября 2013 в 20:01
85

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

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

avatar
Rohitashv Singhal
4 июня 2013 в 14:08
51

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

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

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

т.е. git pull = git fetch + git merge ...

avatar
Snowcrash
13 апреля 2013 в 17:31
253

Кратко

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/

avatar
MikeD
31 марта 2013 в 18:43
1288

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

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

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

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

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

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

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

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

Emil Lundberg
14 августа 2013 в 09:51
81

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

avatar
Selvamani
21 февраля 2013 в 13:25
91

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

git pull == git fetch + git merge

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

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

avatar
ntanase
26 ноября 2012 в 21:58
80

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

avatar
pn1 dude
17 июля 2012 в 16:43
111

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

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

avatar
Gerardo
11 мая 2012 в 18:37
391

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

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

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

Итак, разница будет:

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

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

avatar
Mouna Cheikhna
18 августа 2011 в 08:53
2321
  • Когда вы используете pull, Git пытается автоматически выполнить слияние. Это контекстно-зависимый , поэтому Git объединит любые извлеченные коммиты в ветку, над которой вы сейчас работаете. pull автоматически объединяет коммиты , не позволяя вам предварительно просмотреть их . Если вы не будете тщательно управлять своими ветвями, вы можете часто сталкиваться с конфликтами.

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

Lee Dixon
13 мая 2013 в 18:44
37

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

elexhobby
5 июня 2013 в 19:15
0

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

Tino
17 июля 2013 в 06:48
138

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

Chris
12 сентября 2013 в 21:49
28

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

carloswm85
12 августа 2021 в 20:44
0

Итак, команда fetch - это что-то вроде «фиксации с удаленного на локальный». Правильно?

avatar
jfmercer
15 мая 2011 в 20:53
168

Краткий и простой ответ: 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) внимательно.

avatar
Antonio Bardazzi
21 марта 2011 в 11:07
171

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

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

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master
Justin Ohms
31 августа 2012 в 20:02
36

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

avatar
mepster
7 мая 2010 в 19:23
520

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

git fetch
git diff ...origin

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

avatar
Vinko Vrsalovic
15 ноября 2008 в 09:52
189
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.

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