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

Question

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

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

Answer 1

Проще говоря, git pull делает git fetch с последующим git merge,

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

git fetch
git diff ...origin

Answer 6

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

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

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

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

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

Answer 7

кратко

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 Вот. См. Комментарий Джастина Ома в другом ответе.

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

Answer 8

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

Answer 9

git-pull - извлечение и объединение с другим хранилищем или локальной веткой
СИНТАКСИС

дерьмо тянуть...
ОПИСАНИЕ

Запускает git-fetch с заданными параметрами и вызывает git-merge для объединения 
извлек голову (и) в текущую ветку. С --rebase вызывает git-rebase 
вместо мерзавца

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

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

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

Answer 10

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

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

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

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

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

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

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

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

---

мерзавец

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

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

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

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

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

---

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

Answer 11

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

Answer 12

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

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

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

Answer 13

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

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

Answer 14

Бонус:

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

git pull --rebase

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

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

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

Answer 15

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

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

Answer 16

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

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

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

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

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

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

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

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

Answer 17

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

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

Answer 18

Из этого замечательного урока Attlassian:

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

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

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

В каталоге вашего проекта (т.е. где вы делаете 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 каталог, затем объединить с вашим локальным, а затем изменить голову внутри /.git/refs/heads каталог.

---

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

Также поищите "Слэш нотация" в посте соглашений об именах веток Git.

Answer 19

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

git pull == git fetch + git merge

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

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

Answer 20

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

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

Answer 21

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

Answer 22

Git Fetch

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

Git Merge

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

Git Pull

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

Answer 23

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

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

git fetch только извлекает из удаленной ветки но не сливает

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

Answer 24

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

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

Answer 25

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

Answer 26

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

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

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

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

Answer 27

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

Answer 28

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

Вот,

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

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

Answer 29

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

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

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

Answer 30

git pull == (git fetch + git merge)

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

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