it-roy-ru.com

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

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

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

10728
pupeno

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

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

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

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

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

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

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

1969
Mouna Cheikhna

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

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

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

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

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

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

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

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

1104
MikeD

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

enter image description here

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

744
Contango

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

git fetch
git diff ...Origin
446
mepster

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

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

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

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

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

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

 enter image description here

195
thedarkpassenger

Кратко

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

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

Больше

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

git rebase сохраняет данные из вашей текущей ветки, которых нет в ветке upstream, во временную область. Ваша ветка теперь такая же, как и до того, как вы начали свои изменения. Таким образом, 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/

189
Snowcrash
 git-pull - Выбрать и объединить с другим репозиторием или локальной ветвью 
 Синтаксис 

 git pull… 
 ОПИСАНИЕ 

 Запускает git-fetch с заданными параметрами, и вызывает git-merge для слияния извлеченных голов 
 в текущую ветку. С --rebase вызывает git-rebase 
 Вместо git-merge .

 Обратите внимание, что вы можете использовать. (текущий каталог) в качестве <репозитория> для извлечения 
 из локального репозитория - это полезно при объединении локальных ветвей 
 в текущую ветвь .

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

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

164
Vinko Vrsalovic

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

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

git checkout master                                                  
git fetch                                        
git diff Origin/master
git rebase Origin master
151
Antonio Bardazzi

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

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

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

git pull Origin master
git checkout foo-branch
git rebase master
git Push Origin foo-branch

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

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

145
jfmercer

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

мерзкий выбор

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

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

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

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

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

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


мерзавец

Это применит изменения от remote к current branch в локальном ...

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

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

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

Значения по умолчанию для и считываются из Конфигурация "remote" и "merge" для текущей ветви, как установлено git-branch --track.


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

 git pull and git fetch

126
Alireza

enter image description here

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

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

121
th3sly

Бонус:

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

git pull --rebase

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

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

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

119
Sazzad Hissain Khan

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

                                         LOCAL SYSTEM
                  . =====================================================    
================= . =================  ===================  =============
REMOTE REPOSITORY . REMOTE REPOSITORY  LOCAL REPOSITORY     WORKING COPY
(Origin)          . (CACHED)           
for example,      . mirror of the      
a github repo.    . remote repo
Can also be       .
multiple repo's   .
                  .
                  .
FETCH  *------------------>*
Your local cache of the remote is updated with the Origin (or multiple
external sources, that is git's distributed nature)
                  .
PULL   *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur, 
you are asked for decisions.
                  .
COMMIT            .                             *<---------------*
When coming from, for example, Subversion, you might think that a commit
will update the Origin. In git, a commit is only done to your local repo.
                  .
Push   *<---------------------------------------*
Synchronizes your changes back into the Origin.

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

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

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

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

99
pn1 dude

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

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

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

 enter image description here

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

 enter image description here

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

1. Git Fetch- Это загрузит все изменения, которые были внесены в проект Origin/main ветки, которых нет в вашей локальной ветке. И будет ждать, пока команда 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

89
Aman Tiwari

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

git pull == git fetch + git merge

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

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

82
Selvamani

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

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

80
Michael Durrant

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

75
ntanase

Git Fetch

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

Git Merge

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

Git Pull

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

71
Pinkesh Sharma

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

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

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

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

50
Rohitashv Singhal

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

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

    (репо к операции репо) [email protected] >> remote/Origin/[email protected]

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

    (операция внутреннего репо) remote/Origin/[email protected] >> [email protected]

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

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

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

git pull - это git fetch и git merge

44
Pawel Furmaniak

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

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

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

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

36
Donal

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

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

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

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

     git pull Origin master

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

35
Marcus Thornton

git pull == (git fetch + git merge) 

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

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

33
Iggy

На самом деле Git поддерживает копию вашего собственного кода и Удаленного хранилища.

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

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

32
Pokemon

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

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

31
montells

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

 enter image description here

вот,

git pull  

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

но в , 

мерзкий выбор 

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

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

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

git pull Origin master

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

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

git fetch Origin master

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

git rebase Origin/master

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

30
Mohideen ibn Mohammed
git pull = git fetch + git merge 
29
Saqib R.

From Pro Git § 2.5 Основы Git - Работа с Remotes: Извлечение и извлечение из ваших Remotes :

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

Если у вас настроена ветка для отслеживания удаленной ветки, вы можете использовать Команда git pull для автоматического извлечения и последующего объединения удаленного перейти в вашу текущую ветку. Это может быть проще или больше удобный рабочий процесс для вас; и по умолчанию команда git clone автоматически настраивает вашу локальную главную ветку для отслеживания удаленного основная ветвь на сервере, с которого вы клонировали (при условии, что у удаленного есть главная ветвь ). Запуск git pull обычно выбирает данные из сервер, с которого вы изначально клонировали и автоматически пытается объединить его в код, над которым вы сейчас работаете.

28
Zhenxiao Hao

git pull 

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

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

git fetch

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

git fetch
git rebase Origin/master
22
Animesh Sharma

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

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

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

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

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

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

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

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

22
g24l

От мерзавец шпаргалка

git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD
20
Nan Xiao

Из того, что я понял, 

Git pull - Тянет вниз с указанного удаленного (указанного пользователем) и мгновенно объединит его в ветку, в которой мы сейчас находимся. Это в основном смесь команд Fetch и Merge.

Git Fetch - Это то же самое, что Pull, но не будет объединяться. Таким образом, вы можете тщательно отслеживать файлы перед их объединением. 

Этот URL должен быть полезен для дальнейшего понимания: Разница между git pull, git fetch и git clone (и git rebase).

17
Pragyaditya Das

Кратко и просто:

git fetch: посмотрите, есть ли новые вещи.

git pull: Возьмите новый материал и поместите его поверх своего материала. 

8
miva2

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

 Enter image description here

Извлечение может быть полезно, когда вам нужно получить обновление от других разработчиков, но при этом хотите продолжить работу без помех. Люди, которые часто хотят выходить из сети и работать, используют fetch, чтобы получать последние обновления, пока она/он не был в сети. Позже, когда она/он устраивает ее изменения, объединяет те из ветви в его/ее рабочее пространство.

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

5
ishandutta2007

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

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

3
Andrei Todorut

Git fetch синхронизирует каталог удаленного репозитория с вашим локальным. Он не объединит изменения файла/кода с удаленного в ваше локальное отделение.

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

1
Arnel Lenteria

Из этого классного Attlassian учебник: 

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

Извлечение - это то, что вы делаете, когда хотите увидеть, над чем работают все else. Он похож на svn update в том, что он позволяет увидеть, как продвигается центральная история, но не заставляет вас фактически объединять изменения в вашем хранилище. Git изолирует извлеченный контент как a от существующего локального контента, он абсолютно не влияет на вашу локальную работу по разработке. Извлеченное содержимое должно быть явно извлечено с помощью команды 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 хранит новые коммиты?

Отличный вопрос Это помещает это куда-то изолированное от вашей рабочей копии. Но опять же где? Давайте разберемся.

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

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

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

  3. Do cd .git. Это, очевидно, изменит ваш каталог. 
  4. Теперь самое интересное; сделать ls. Вы увидите список каталогов. Мы ищем refs. Do cd refs.
  5. Интересно посмотреть, что находится внутри всех каталогов, но давайте сосредоточимся на двух из них. heads и remotes. Используйте cd, чтобы проверить внутри них тоже. 
  6. ЛЮБОЙ git fetch, который вы делаете, будет обновлять элементы в каталоге /.git/refs/remotes. Он не будет обновлять ничего в каталоге /.git/refs/heads.
  7. ЛЮБОЙ git pull сначала выполнит git fetch, обновит элементы в каталоге /.git/refs/remotes, затем объединится с вашим локальным сервером, а затем изменит заголовок внутри каталога /.git/refs/heads

Также может быть найден очень хороший связанный ответ Где находится «git fetch»?

Также поищите «Слэш нотация» из Соглашения об именах веток Git post.

1
Honey