Проще говоря, 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 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.

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

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

git fetch
git diff ...origin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 философии более традиционного инструмента управления версиями, такого как SVN.

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

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

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

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

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

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

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

Вкратце

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 pull и git fetch заключается в следующем:

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

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

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

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 получает ветку последней версии с удаленного на локальный с помощью двух команд:

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

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

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

What is the difference between git pull and git fetch?

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

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

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

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

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

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 Fetch

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

Git Merge

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

Git Pull

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

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

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

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

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

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

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

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

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

В ПОРЯДКЕ, вот некоторая информация о 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  

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

но в ,

git fetch

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

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

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

git pull origin master

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

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

git fetch origin master

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

git rebase origin/master

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

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

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

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

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

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

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

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

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