Примечание модератора. Учитывая, что на этот вопрос уже было отправлено шестьдесят семь ответов (некоторые из них были удалены), подумайте, не вносите ли вы что-либо новое перед отправкой другого.
Каковы различия между git pull
и git fetch
?
Проще говоря, 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
.
git pull
всегда будет сливаться с текущей веткой . Таким образом , вы выбираете какую ветвь вы хотите , чтобы вытащить из, и она тянет его в текущую ветку. Филиал from может быть локальным или удаленным; это может быть даже удаленная ветка, которая не является зарегистрированным git remote
(то есть вы передаете URL в командной строке git pull
).
Когда вы используете 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
чтобы обновить локальную копию удаленного репозитория, а затем объединить изменения в свой собственный репозиторий кода и, возможно, вашу рабочую копию.
Убрать это, чтобы иметь в виду, что на вашей рабочей станции часто не менее трех копий проекта. Один экземпляр - это ваш собственный репозиторий со своей собственной историей фиксации. Вторая копия - это ваша рабочая копия, где вы редактируете и строите. Третья копия - это ваша локальная "кэшированная" копия удаленного репозитория.
remoteName/
Git с нуля являются очень хорошим чтением. Как только вы получите представление о том , как работает Git - и это красиво просто, на самом деле - все просто имеет смысл.
Вот образ Оливера Стил, как все это сочетается:
Если есть достаточный интерес, я полагаю, я мог бы обновить изображение, чтобы добавить git clone
и git merge
...
git clone
и git merge
было бы очень полезно!
git merge
- он должен четко показывать, что merge
вызываемое отдельно, не то же самое, что вызов pull
поскольку pull
объединяется только с удаленного компьютера и игнорирует ваши локальные коммиты в вашей локальной ветви, которая отслеживает удаленную ветку, из которой выполняется извлечение.
Одним из вариантов использования git fetch
является то, что следующее сообщение будет сообщать вам о любых изменениях в удаленной ветке с момента последнего вытягивания... поэтому вы можете проверить, прежде чем делать фактическое вытягивание, которое может изменять файлы в вашей текущей ветке и работать копия.
git fetch
git diff ...origin
git diff ..origin
?
Мне стоило немного понять, в чем разница, но это простое объяснение. master
в вашем localhost есть ветка.
Когда вы клонируете репозиторий, вы получаете весь репозиторий для локального хоста. Это означает, что в это время у вас есть указатель origin/master на HEAD
и мастер, указывающий на тот же HEAD
.
когда вы начинаете работать, и делаете это, вы переводите указатель мастера на HEAD
+ ваши фиксации. Но указатель origin/master все еще указывает на то, что было, когда вы клонировали.
Таким образом, разница будет:
git fetch
, он просто извлечет все изменения в удаленном репозитории (GitHub) и переместите начало/мастер-указатель на HEAD
. Тем временем ваш мастер локального ветки будет продолжать указывать, где он находится.git pull
, он будет выполнять в основном извлечение (как объяснялось ранее) и объединить любые новые изменения в основную ветку и переместить указатель на HEAD
.git fetch
должен был буквально загружать изменения на удаленном репо в ваше локальное репо, но НЕ фиксировать их - то есть, они все еще должны быть добавлены / зафиксированы в вашем локальном репо.
Иногда визуальное представление помогает.
git pull
пропускает выборку, что, конечно, неточно.
кратко
git fetch
похожа на pull
но не сливается. то есть он выбирает удаленные обновления (refs
и objects
), но ваш локальный остается прежним (т.е. origin/master
обновляется, но master
остается прежним).
git pull
сносит с пульта и мгновенно сливается.
Больше
git clone
клонирует репо.
git rebase
сохраняет данные из вашей текущей ветки, которые не находятся в ветке upstream, во временную область. Ваша ветка теперь такая же, как и до того, как вы начали свои изменения. Итак, git pull -rebase
будет git pull -rebase
удаленные изменения, перематывать вашу локальную ветку, воспроизводить ваши изменения поверх текущей ветки по одному, пока вы не будете в курсе.
Также git branch -a
покажет вам, что происходит со всеми вашими ветками - локальными и удаленными.
Этот пост был полезен:
Разница между git pull, git fetch и git clone (и git rebase) - Майк Пирс
и охватывает git pull
, git fetch
, git clone
и git rebase
.
====
ОБНОВИТЬ
Я думал, что обновлю это, чтобы показать, как вы на самом деле используете это на практике.
Обновите локальное хранилище с удаленного компьютера (но не объединяйте):
git fetch
После загрузки обновлений, давайте посмотрим на различия:
git diff master origin/master
Если вы довольны этими обновлениями, то объедините:
git pull
Заметки:
На шаге 2: Для получения дополнительной информации о различиях между локальным и удаленным, см.: Как сравнить локальную ветку git с ее удаленной веткой?
На шаге 3: Вероятно, более точным (например, в быстро меняющемся репо) является создание источника git rebase origin
здесь. См. Комментарий Джастина Ома в другом ответе.
Смотрите также: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
git clone
. Я поместил подсказку в кавычки, поскольку я предполагаю, что это будет означать, какой бы мастер ни был, и что кто-то будет «скачать как zip» с github.com
git-pull - Fetch from and merge with another repository or a local branch SYNOPSIS git pull … DESCRIPTION Runs git-fetch with the given parameters, and calls git-merge to merge the retrieved head(s) into the current branch. With --rebase, calls git-rebase instead of git-merge. Note that you can use . (current directory) as the <repository> to pull from the local repository — this is useful when merging local branches into the current branch. Also note that options meant for git-pull itself and underlying git-merge must be given before the options meant for git-fetch.
Вы бы потянули, если хотите, чтобы истории слились, вы бы получили, если бы вы просто "хотели код", поскольку кто-то из них помещал некоторые статьи здесь.
git fetch
он выбирает изменения из репозитория и обновляет вашу локальную удаленную ветку. Это не влияет на вашу локальную ветку, которая отслеживает локальную удаленную ветку, поэтому не влияет на вашу рабочую копию. Теперь, когда вы сделаете merge
оно объединит извлеченные изменения с вашей локальной веткой.
Вы можете извлечь из удаленного репозитория, увидеть различия, а затем вытащить или объединить.
Это пример удаленного репозитория с именем 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 --rebase
не подходит для данной ситуации, правильно ли это, если это делается в два этапа? Если это правильно, какая польза от этого в два этапа?
Это интерактивное графическое представление очень полезно при понимании git: http://ndpsoftware.com/git-cheatsheet.html
git fetch
просто "загружает" изменения с пульта в локальный репозиторий. git pull
загружает изменения и объединяет их в вашу текущую ветку. "В режиме по умолчанию git pull
является сокращением для git fetch
, за которым следует git merge FETCH_HEAD
."
Говоря о вытягивании и извлечении в приведенных выше ответах, я хотел бы поделиться интересным трюком,
git pull --rebase
Эта вышеприведенная команда является самой полезной командой в моей жизни git, которая сэкономила много времени.
Прежде чем нажимать новые коммиты на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения сервера (с помощью fetch + merge) и поместит ваше сообщение в начало в журнал git. Не нужно беспокоиться о ручном вытягивании/слиянии.
Найти информацию по адресу: http://gitolite.com/git-pull--rebase
git pull
и git pull --rebase
?
Хорошо, вот некоторые сведения о 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/heads/: refs/remotes/origin/), но обычно это имя ветки в удаленном репозитории.
Значения по умолчанию для и считываются из конфигурации "remote" и "merge" для текущей ветки, как установлено git-branch --track.
Я также создаю визуальное изображение ниже, чтобы показать вам, как git fetch
и git pull
работают вместе...
Мне нравится иметь какое-то визуальное представление о ситуации, чтобы понять эти вещи. Может быть, другие разработчики тоже хотели бы это увидеть, так что здесь мое дополнение. Я не совсем уверен, что все правильно, поэтому, пожалуйста, прокомментируйте, если вы обнаружите какие-либо ошибки.
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 .
.
.
FETCH *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git 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.
Некоторые основные преимущества наличия зеркального отображения пульта:
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 можно объяснить следующим сценарием: (Помня, что картинки говорят громче слов !, я предоставил графическое представление)
Давайте предположим, что вы работаете над проектом с членами вашей команды. Таким образом, их будет одним из основных подразделений проекта, и все участники должны разветкить его в своем собственном локальном репозитории, а затем работать над этим локальным филиалом, чтобы изменить/добавить модули, а затем вернуться к основной ветке.
Итак, начальное состояние двух ветвей, когда вы разветвляете основной проект в своем локальном репозитории, будет как this- (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 fetch
выводит код с удаленного сервера на ваши ветки отслеживания в локальном репозитории. Если ваш пульт называется origin
(по умолчанию), то эти ветки будут находиться в пределах origin/
, например origin/master
, origin/mybranch-123
и т.д. Это не ваши текущие ветки, они являются локальными копиями этих ветвей из сервер.
git pull
делает git fetch
, но затем также объединяет код из ветки отслеживания в вашу текущую локальную версию этой ветки. Если вы еще не готовы к этим изменениям, сначала git fetch
.
Мы просто говорим:
git pull == git fetch + git merge
Если вы запустите git pull
, вам не нужно объединять данные с локальными. Если вы запустите git fetch
, это означает, что вы должны запустить git merge
для получения последнего кода на вашем локальном компьютере. В противном случае локальный машинный код не будет изменен без слияния.
Итак, в Git Gui, когда вы делаете выборку, вам нужно объединить данные. Извлечь сам себя не приведет к изменению кода на вашем локальном компьютере. Вы можете проверить, что при обновлении кода путем выборки после извлечения и просмотра; код он не изменится. Затем вы объединяетесь... Вы увидите измененный код.
git pull == git fetch + git merge
:)
git pull --rebase = git fetch + git rebase
git fetch
будет извлекать удаленные ветки, чтобы вы могли git diff
или git merge
их с текущей ветвью. git pull
будет запускать выборку на удаленном плече, отслеживаемом текущей ветвью, а затем слить результат. Вы можете использовать git fetch
, чтобы узнать, есть ли какие-либо обновления удаленной ветки без необходимости их слияния с вашей локальной ветвью.
Git Fetch
Вы загружаете изменения в локальную ветку из источника через выборку. Fetch запрашивает удаленное репо для всех коммитов, которые сделали другие, но у вас нет на вашем локальном репо. Fetch загружает эти коммиты и добавляет их в локальный репозиторий.
Git Слияние
Вы можете применить изменения, загруженные через выборку, с помощью команды merge. Merge берет полученные из выборки коммиты и пытается добавить их в локальную ветку. Слияние будет сохранять историю фиксации ваших локальных изменений, так что, когда вы делитесь своей веткой с push, Git будет знать, как другие могут объединить ваши изменения.
Git Pull
Считать и слить вместе достаточно часто, чтобы была создана команда, которая объединяет два, pull. Pull делает выборку, а затем слияние, чтобы добавить загруженные коммиты в вашу локальную ветвь.
Единственное различие между git pull
и git fetch
заключается в следующем:
git pull
извлекает из удаленной ветки и объединяет его.
git fetch
извлекает только из удаленной ветки, но не объединяется
то есть. git pull = git fetch + git merge...
rm -rf
вперед», что, в конце концов, я все закончил и начал все сначала. Глупый мерзавец, пожалуйста, просто дай мне знать, чтобы я мог вернуться к работе?
Git позволяет хронологически более старые коммиты применяться после того, как новые коммиты. Из-за этого акт передачи фиксации между репозиториями делится на два этапа:
Копирование новых коммитов из удаленной ветки для копирования этой удаленной ветки внутри локального репо.
(операция репо для операции репо) master@remote >> remote/origin/master@local
Интеграция новых коммитов в локальную ветвь
(операция внутри-репо) remote/origin/master@local >> master@local
Есть два способа сделать шаг 2. Вы можете:
В терминологии git
шаг 1 равен git fetch
, шаг 2 равен git merge
или git rebase
git pull
составляет git fetch
и git merge
В чем разница между
git pull
иgit fetch
?
Чтобы понять это, вам сначала нужно понять, что ваш локальный git поддерживает не только ваш локальный репозиторий, но также поддерживает локальную копию удаленного репозитория.
git fetch
обновляет локальную копию удаленного репозитория. Например, если ваш удаленный репозиторий - это GitHub - вы можете захотеть извлечь любые изменения, сделанные в удаленном репозитории, в локальную копию этого удаленного хранилища. Это позволит вам выполнять такие операции, как сравнение или слияние.
git pull
, с другой стороны, приведет к смене изменений в удаленном репозитории, где вы сохраните свой собственный код. Как правило, git pull
сначала выполнит git fetch
, чтобы обновить локальную копию удаленного репозитория, а затем объединить изменения в свой собственный репозиторий кода и, возможно, вашу рабочую копию.
Git получает ветку последней версии от удаленного к локальному, используя две команды:
git fetch: Git собирается получить последнюю версию с удаленного на локальный, но она не будет автоматически сливаться.
git fetch origin master
git log -p master..origin/master
git merge origin/master
Приведенные выше команды означают, что загружать последнюю версию основной ветки из источника из удаленной в исходную ветвь оригинала. А затем сравнивает локальную ветвь ведущей ветки и начальную ветвь. Наконец, слейте.
Git pull: Git собирается получить последнюю версию с пульта и слить в локальный.
git pull origin master
Приведенная выше команда эквивалентна git fetch
и git merge
. На практике git fetch
может быть более безопасным, поскольку перед слиянием мы можем видеть изменения и решать, сходиться ли.
Фактически Git хранит копию вашего собственного кода и удаленный репозиторий.
Команда git fetch
обновляет локальную копию, получая данные из удаленного репозитория. Причина, по которой мы нуждаемся в этом, - это то, что кто-то другой мог внести некоторые изменения в код, и вы хотите сохранить себя обновленным.
Команда git pull
приносит изменения в удаленном репозитории, где вы храните свой собственный код. Обычно git pull
делает это, делая сначала
Попытка быть понятной и простой.
Команда git pull на самом деле является shortcut
для git fetch, за которой следует git слияние или git rebase в зависимости от вашей конфигурации. Вы можете настроить репозиторий Git, чтобы git pull - выборка, за которой следует rebase.
git pull == (git fetch + git merge)
git fetch не изменяется на локальные ветки.
Если у вас уже есть локальный репозиторий с удаленной настройкой для желаемого проекта, вы можете захватить все ветки и теги для существующего удаленного с помощью git fetch.... Fetch не вносит никаких изменений в локальные ветки, поэтому вам необходимо объединить удаленную ветку с парным локальным ветвью для включения новых изменений извлечения. из github
Простое графическое представление для начинающих,
здесь
git pull
будет извлекать код из репозитория и переадресовывать с вашим локальным... в git pull есть возможность создания новых коммитов.
но в,
git fetch
будет извлекать код из репозитория, и мы должны его переустановить вручную, используя git rebase
например: я собираюсь извлечь из главного сервера и переустановить его в локальном хозяине.
1) git pull (rebase будет выполняться автоматически):
git pull origin master
здесь origin - ваш удаленный репо мастер - это ваша ветка
2) git fetch (необходимо переустановить вручную):
git fetch origin master
он будет получать изменения сервера из источника. и он будет в вашем местном, пока вы не переустановите его самостоятельно. мы должны исправлять конфликты вручную, проверяя коды.
git rebase origin/master
это приведет к замене кода на локальный. перед этим убедитесь, что вы находитесь в правильной ветке.
git pull = git fetch + git merge
Важно отметить, что команда
fetch
выводит данные в ваш локальный репозиторий - это doesnt автоматически объединить его с любой из ваших работ или изменить то, что вы в настоящее время работает. Вы должны объединить его вручную в свою работу когда вы готовы.Если у вас есть ветвь, настроенная для отслеживания удаленной ветки, вы можете использовать
git pull
для автоматического извлечения, а затем слияния удаленного войдите в свою текущую ветку. Это может быть проще или более удобный рабочий процесс для вас; и по умолчанию командаgit clone
автоматически настраивает локальную ведущую ветвь для отслеживания удаленного master на сервере, с которого вы клонировали (при условии, что мастер-ветвь). Выполнениеgit pull
обычно выбирает данные из сервер, с которого вы первоначально клонировали, и автоматически пытается слить его в код, который вы сейчас работаете.
git pull
Он выполняет две функции, используя одну команду.
Он извлекает все изменения, внесенные в удаленную ветку, а затем объединяет эти изменения в локальную ветвь. Вы также можете изменить поведение pull, пройдя --rebase. Разницу между слиянием и rebase можно прочитать здесь
git fetch
Git fetch выполняет только половину работы git pull. Он просто переносит удаленные изменения в локальное репо, но не применяет их к вашим ветким. Вы должны явно применять эти изменения. Это можно сделать следующим образом:
git fetch
git rebase origin/master
Следует иметь в виду природу git. У вас есть пульты и ваши локальные ветки (не обязательно одинаковые). По сравнению с другими системами управления источниками, это может быть немного озадачивающим.
Обычно при проверке удаленного компьютера создается локальная копия, которая отслеживает удаленный доступ.
git fetch будет работать с удаленной ветвью и обновлять вашу информацию.
На самом деле, если другие SWE работают одна и та же ветвь, и редко случай в маленьком одном dev - один ветки - один сценарий проекта.
Ваша работа над локальным филиалом по-прежнему не повреждена. Чтобы внести изменения в локальную ветвь, вам необходимо объединить/переустановить изменения из удаленной ветки.
git pull выполняет именно эти два шага (то есть --rebase для rebase вместо слияния)
Если ваша локальная история и удаленная история имеют конфликты, вы будете вынуждены выполнять слияние во время нажатия git, чтобы опубликовать ваши изменения.
Таким образом, это действительно зависит от характера вашей рабочей среды и опыта использования.
Из git чит-листа:
git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD
Git Pull:
Из того, что я понимаю, git pull вытащит из удаленного все, что вы просите (так что независимо от того, что запрашивается у вас), и мгновенно объединить его в ветку, когда вы делаете запрос. Pull - это запрос высокого уровня, который запускает "выборка", а затем "слияние по умолчанию" или "перебаза с" -ребазой. Вы могли бы обойтись без этого, это просто удобство.
%> git checkout localBranch
%> git pull origin master
%> git branch
master
* localBranch
Вышеупомянутое объединит удаленную "ведущую" ветвь в локальный "localBranch".
Git fetch:
Fetch похож на pull, за исключением того, что он не будет слияния.
%> git checkout localBranch
%> git fetch origin remoteBranch
%> git branch
master
* localBranch
remoteBranch
Таким образом, выборка приведет к удалению удаленного узла и поместит его в локальный ветвь с именем "remoteBranch". создает локальную копию удаленной ветки, которую вы не должны манипулировать напрямую; вместо этого создайте надлежащую локальную ветку и поработайте над этим. "git checkout имеет запутанную функцию. Если вы проверяете локальную копию удаленного ветки, он создает локальную копию и устанавливает для нее слияние по умолчанию.
выбрать vs pull
fetch будет загружать любые изменения из удаленной ветки, обновляя данные вашего репозитория, но оставляя ваш локальный филиал без изменений.
pull выполнит выборку и дополнительно объединит изменения в вашу локальную ветвь.
Какая разница? вытаскивает обновленную локальную ветвь с изменениями из вытащенной ветки. Извлечение не продвигает вашу локальную ветвь.
Из того, что я понял,
Git pull. Вытягивает с указанного пульта (указанный пользователем) и мгновенно объединяет его в ветку, в которой мы сейчас находимся. Это в основном сочетание команд Fetch и Merge.
Git Fetch. Это то же самое, что и Pull, но он не будет слияния. Таким образом, вы можете тщательно контролировать файлы перед слиянием.
Этот url должен помочь в дальнейшем понимании: Разница между git pull, git fetch и git clone (и git rebase).
Fetch
$git fetch origin
Git Fetch загружает только новые данные из удаленного репозитория - но он не интегрирует какие-либо из этих новых данных в ваши рабочие файлы. Fetch отлично подходит для получения свежего представления обо всех вещах, которые произошли в удаленном репозитории.
Из-за своей безвредной природы вы можете быть уверены, что выборка никогда не будет манипулировать, уничтожать или ничего не испортить. Это означает, что вы никогда не сможете получить достаточно часто.
Вытащите
$git мастер создания тяги
Git Pull, напротив, используется с другой целью: обновить текущую ветку HEAD с последними изменениями с удаленного сервера. Это означает, что pull не только загружает новые данные, но и напрямую интегрирует их в ваши текущие файлы рабочей копии.
Это имеет несколько следствий:
Так как "git pull" пытается объединить удаленные изменения с вашими локальными, может возникнуть так называемый "конфликт слияния".
Как и во многих других действиях, настоятельно рекомендуется запустить "git pull" только с чистой рабочей копией.
Это означает, что перед тем, как вы потянете, у вас не должно быть никаких локальных изменений. Используйте функцию Git s Stash, чтобы временно сохранить локальные изменения.
Короче говоря, просто:
git fetch
: Посмотрите, есть ли новые вещи.
git pull
: Возьмите новый материал и положите его поверх своих вещей.
Проще говоря, если вы собираетесь запрыгнуть на без интернета... перед отъездом вы можете просто сделать git fetch origin <master>
. Он будет загружать все изменения на ваш компьютер, но держать его отдельно от вашей локальной разработки/рабочей области.
В самолете вы можете внести изменения в свое локальное рабочее пространство, а затем объединить его с тем, что вы получили, и разрешить потенциальные конфликты объединения без Интернета. И если кто-то не внес новые противоречивые изменения в удаленное хранилище, то, как только вы прибудете в пункт назначения, вы выполните git push origin <branch>
и отправитесь за кофе.
Из этого замечательного урока 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
) выполните:
ls
Это покажет файлы и каталоги. Ничего крутого, я знаю.
Теперь сделайте ls -a
. Это покажет точечные файлы, т.е. файлы, начинающиеся с .
После этого вы сможете увидеть каталог с именем: .git
.
cd.git
. Это, очевидно, изменит ваш каталог.ls
Вы увидите список каталогов. Мы ищем refs
. Сделайте cd refs
.heads
и remotes
. Используйте cd
чтобы проверить внутри них тоже.git fetch
которые вы делаете, обновят элементы в каталоге /.git/refs/remotes
. Он ничего не обновит в каталоге /.git/refs/heads
.git pull
сначала выполняет git fetch
, обновляет элементы в каталоге /.git/refs/remotes
, затем объединяется с вашим локальным каталогом, а затем изменяет /.git/refs/heads
каталоге /.git/refs/heads
.Также может быть найден очень хороший ответ. Где размещается "git fetch"?
Также обратите внимание на "Слеш нотацию" в посте соглашений об именах веток Git.
Я считаю, что большинство ответов ответили на разницу достаточно хорошо. Я хотел бы подчеркнуть, когда использовать это вместо этого.
Fetch может быть полезен, когда вам нужно получить обновление от других разработчиков, но хотите продолжить работу без изменений. Люди, которые часто хотят отключиться и работают, используют fetch
для получения последнего обновления, пока он/она не будет в сети. Позже, когда он/она устраивает ее изменения, сливает те из ветки в свое рабочее пространство.
В то время как люди, которые работают в Интернете и очень уверены в своих изменениях и хотят, чтобы получить последнюю версию кода и merge
сразу использует pull
. Я редко использую fetch
потому что для проверки последних обновлений я проверяю их через веб-сайт GitHub, и я всегда работаю в автономном режиме. Как я уже говорил, вы можете использовать этот сценарий.
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 fetch загружает последние изменения с удаленного устройства, но не влияет на вашу рабочую копию или ветки в локальном репозитории. Загруженная ветвь хранится в /, например. Происхождение/хозяин.
git pull эффективно git fetch, за которым следует git merge/. Любые изменения в удаленном репозитории объединяются в вашу локальную ветвь. Это полезно, если вы просто хотите, чтобы ваш локальный репозиторий отражал изменения, которые произошли на удаленном компьютере, но, как правило, контрпродуктивен, когда вы работаете в своих ветких и сотрудничаете с другими на удаленном компьютере.
Git fetch синхронизирует каталог удаленного репозитория с вашим локальным. Он не будет объединять изменения файла/кода с удаленного компьютера в локальную ветвь.
Git pull загружает изменения, связанные с вашей текущей локальной ветвью, а затем объединяет их.
git pull = git fetch + git merge
git pull
:
git pull
является сокращением для git fetch
, за которым следует git merge FETCH_HEAD
.git fetch
При выполнении запроса на растяжение в eclipse мы можем видеть git fetch и обновлять результаты следующим образом:
Взгляните на рисунок ниже, это пример sourcetree или извлеченные, но не вытащенные изменения.
1) После извлечения эти цифры показывают, сколько наборов изменений не объединено с текущей рабочей копией. В режиме просмотра ST ваш выбранный набор изменений НЕ будет последним по дате (красная стрелка) в выбранной ветке. Рабочее пространство не будет затронуто после извлечения, потому что это всего лишь синхронизация сделанных наборов изменений с удаленным репо.
2) Если нажать Pull, текущая рабочая копия будет обновлена со всеми этими наборами изменений, и в режиме просмотра журнала выбранный вами набор изменений будет последним в рабочей ветке. Кроме того, могут возникнуть конфликты слияния.
git fetch; git reset --hard origin/master
как часть нашего рабочего процесса. Он сносит локальные изменения, держит вас в курсе, но главное гарантирует, что вы не будете просто вносить новые изменения поверх текущих изменений и создавать беспорядок. Мы использовали его некоторое время, и на практике это выглядит намного безопаснее. Просто убедитесь, что добавили / зафиксировали / спрятали любую незавершенную работу в первую очередь!