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

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

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

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

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

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

• git fetch - это команда, которая говорит: "Принесите мой местный копию удаленного репозитория в актуальном состоянии."

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

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

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

здесь Оливер Стил образ того, как все это все вместе:

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

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

git fetch
git diff ...origin

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

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

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

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

• если вы git fetch Он просто получит все изменения в удаленном репозитории (GitHub) и переместите указатель origin / master в HEAD. Между тем ваш местный мастер филиала будет продолжать указывать, где он имеет.
• если вы git pull, он будет делать в основном fetch (как объяснялось ранее) и объединять любые новые изменения в вашей главной ветви и переместите указатель на 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. Если ты ... --7--> прежде чем тянуть, вы должны иметь некоторое представление о потенциальных конфликтах слияния и могли бы подготовить свою локальную ветвь соответственно.

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

бонус:

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

git pull --rebase

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

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

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

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

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

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

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

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

git fetch

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

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

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

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

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

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

git тяни!--13-->

он будет применять изменения из пульт ДУ до текущая филиала в местный...

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

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

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

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

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

Я тоже боролся с этим. На самом деле я попал сюда с поиском 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 - это загрузит все изменения, которые были внесены в проект origin / main branch, которые отсутствуют в вашем локальном филиале. И будет ждать, пока команда git Merge применит изменения, которые были извлечены в ваш репозиторий или ветку.

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

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

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

git pull == git fetch + git merge

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

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

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

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

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

Git Fetch

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

Git Merge

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

Git Pull

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

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

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

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

т. е. ГИТ тянуть = ГИТ выборки + ГИТ слияния ...

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

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

   (РЕПО операция РЕПО) master@remote >> remote/origin/master@local

2. интеграция новых коммитов в локальную ветвь

   (внутри-РЕПО операции) remote/origin/master@local >> master@local

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

1. локальная ветвь Fork после последнего общего предка и добавление новых коммитов параллельно коммитам, которые уникальны для локального репозитория, завершается слиянием фиксации, закрывая вилку.
2. вставить новые коммиты после последнего общего предка и повторно совершает уникальный для локального репозитория.

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

git pull is git fetch и git merge

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

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

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

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

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

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

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

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

       git pull origin master

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

git pull = = (git fetch + git merge)

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

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

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

на git pull

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

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

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

git pull = git fetch + git merge 

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

здесь

git pull  

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

но ,

git fetch

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

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

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

git pull origin master

здесь origin ваш удаленный РЕПО мастер ваш филиал

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

git fetch origin master

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

git rebase origin/master

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