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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git fetch
git diff ...origin

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

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

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

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

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

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

Вкратце

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

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

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

Это пример удаленного репозитория с именем 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:

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

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

git fetch

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

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

По умолчанию также выбирается любой тег, указывающий на извлекаемые истории; эффект заключается в получении тегов, указывающих на интересующие вас ветви. Это поведение по умолчанию можно изменить с помощью параметров --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. может назвать произвольную удаленную ссылку (например, имя тега) или даже коллекцию ссылок с соответствующими ветками удаленного отслеживания (например, refs / Heads / : refs / remotes / origin /) , но обычно это имя ветки в удаленном репозитории.

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

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

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

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

Бонус:

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

git pull --rebase

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

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

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

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

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

Я тоже боролся с этим. Фактически, я попал сюда с поиском в 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 Pull можно объяснить следующим сценарием: (Помня о том, что изображения говорят громче, чем слова !, я предоставил графическое изображение )

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

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

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

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

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

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

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

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

git pull == git fetch + git merge

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

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

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

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

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

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

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

Из этого замечательного руководства по Atlassian:

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

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

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

С git pull:

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

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

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

В каталоге вашего проекта (т.е. там, где вы выполняете свои 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 пост. Это поможет вам лучше понять, как Git размещает вещи в разных каталогах.

Чтобы увидеть настоящую разницу

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

git fetch origin master
git checkout master

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

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

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

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

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

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

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

Веселый совет:

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

git fetch origin feature/123

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

git checkout feature/123

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

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

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

Git Fetch

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

Git Merge

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

Git Pull

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

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

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

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

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

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

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

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

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

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

       git pull origin master

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

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

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

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

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

git pull == (git fetch + git merge)

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

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

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

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

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

здесь,

git pull  

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

но в ,

git fetch

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

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

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

git pull origin master

здесь origin - это ваше удаленное репо, master - это ваша ветка

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

git fetch origin master

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

git rebase origin/master

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

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

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

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

git pull

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

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

git fetch

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

git fetch
git rebase origin/master

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

git fetch origin dev/jd/feature/auth

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

git checkout dev/jd/feature/auth

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

git pull origin dev/jd/feature/auth

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

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

git fetch

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

git pull

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

Git Fetch

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

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

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

Git pull

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

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

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

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

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

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

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

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

git fetch origin

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

git pull origin master

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

нам нужно использовать git merge, а затем git pull