git - что - разница между merge and rebase
В чем разница между «git pull» и «git fetch»? (20)
В чем разница между
git pull
иgit fetch
?
Чтобы понять это, вам сначала нужно понять, что ваш локальный git поддерживает не только ваш локальный репозиторий, но также поддерживает локальную копию удаленного репозитория.
git fetch
обновляет локальную копию удаленного репозитория. Например, если ваш удаленный репозиторий - это GitHub - вы можете захотеть извлечь любые изменения, сделанные в удаленном репозитории, в локальную копию этого удаленного хранилища. Это позволит вам выполнять такие операции, как сравнение или слияние.
git pull
с другой стороны, приведет к смене изменений в удаленном репозитории, где вы сохраните свой собственный код. Как правило, git pull
будет делать git fetch
первый довести локальную копию удаленного хранилища до настоящего времени, а затем он будет объединить изменения в свой собственный репозиторий кода и , возможно , вашей рабочей копии.
Примечание модератора. Учитывая, что на этот вопрос уже было отправлено шестьдесят семь ответов (некоторые из них были удалены), подумайте, не вносите ли вы что-либо новое перед отправкой другого.
Каковы различия между git pull
и git fetch
?
Бонус:
Говоря о pull & fetch в приведенных выше ответах, я хотел бы поделиться интересным трюком,
git pull --rebase
Эта вышеприведенная команда является самой полезной командой в моей жизни, которая сэкономила много времени.
Прежде чем нажимать новые коммиты на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения сервера (с помощью слияния + слияние) и поместит вашу фиксацию вверху в журнал git. Не нужно беспокоиться о ручном вытягивании / слиянии.
Найти информацию по адресу: http://gitolite.com/git-pull--rebase
Вот образ Оливера Стил, как все это сочетается :
Если есть достаточный интерес, я полагаю, я мог бы обновить изображение, чтобы добавить git clone
и git 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).
Мне нравится иметь какое-то визуальное представление о ситуации, чтобы понять эти вещи. Возможно, другие разработчики тоже хотели бы это увидеть, так что я добавлю. Я не совсем уверен, что все правильно, поэтому, пожалуйста, прокомментируйте, если вы найдете какие-либо ошибки.
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).
Один из вариантов использования git fetch
заключается в следующем: вы увидите изменения в удаленной ветке с момента последнего нажатия ... так что вы можете проверить, прежде чем делать фактическое нажатие, которое может изменить файлы в вашей текущей ветке и рабочей копии.
git fetch
git diff ...origin
Проще всего, git pull
делает git fetch
за которым следует git merge
.
Вы можете в любой момент выполнить git fetch
для обновления филиалов удаленного отслеживания в разделе refs/remotes/<remote>/
.
Эта операция никогда не изменяет ни одного из ваших собственных местных филиалов в разделе refs/heads
, и безопасно обойтись без изменения вашей рабочей копии. Я даже слышал о том, что люди запускают git fetch
периодически в задании cron в фоновом режиме (хотя я бы не рекомендовал это делать).
git pull
- это то, что вы сделали бы, чтобы обновить локальную ветку с помощью своей удаленной версии, а также обновить другие ветви удаленного отслеживания.
Документация Git: git pull
git fetch
вытаскивает код с удаленного сервера на ваши ветви отслеживания в вашем локальном репозитории. Если ваш пульт назван origin
(по умолчанию), то эти ветки будут находиться origin/
, например origin/master
, origin/mybranch-123
и т. Д. Это не ваши текущие ветви, они являются локальными копиями этих ветвей с сервера.
git pull
делает, git fetch
но затем также объединяет код из ветви отслеживания в вашу текущую локальную версию этой ветви. Если вы еще не готовы к этим изменениям, git fetch
сначала.
Git Fetch
Вы загружаете изменения в локальную ветку из источника через выборку. Fetch запрашивает удаленное репо для всех коммитов, которые сделали другие, но у вас нет на вашем локальном репо. Fetch загружает эти коммиты и добавляет их в локальный репозиторий.
Git Merge
Вы можете применить изменения, загруженные через выборку, с помощью команды слияния. Merge берет полученные из выборки коммиты и пытается добавить их в локальную ветку. Слияние будет сохранять историю фиксации ваших локальных изменений, так что, когда вы делитесь своей веткой с нажатием, Git будет знать, как другие могут объединить ваши изменения.
Git Pull
Fetch и merge run together достаточно часто, чтобы была создана команда, которая объединяет два, pull. Pull делает выборку, а затем слияние, чтобы добавить загруженные коммиты в вашу локальную ветку.
кратко
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
.
====
ОБНОВИТЬ
Я думал, что обновляю это, чтобы показать, как вы на самом деле использовали это на практике.
Обновите локальное репо с удаленного устройства (но не объединяйтесь):
git fetch
После загрузки обновлений, давайте посмотрим различия:
git diff master origin / master
Если вы довольны этими обновлениями, слейте:
git pull
Заметки:
На шаге 2: более подробно о различиях между локальными и удаленными устройствами см.: Сравнить локальную ветвь git с удаленной ветвью?
На шаге 3: Вероятнее всего, это будет более точным (например, при быстром изменении репо), чтобы здесь происходить git rebase origin
. См. Комментарий @Justin Ohms в другом ответе.
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 pull == git fetch + git merge
Если вы запустите git pull
, вам не нужно объединять данные с локальными. Если вы запустите git fetch
, значит, вы должны запустить git merge
для получения последнего кода на вашем локальном компьютере. В противном случае локальный машинный код не будет изменен без слияния.
Поэтому в Git Gui, когда вы делаете выборку, вам нужно объединить данные. Извлечь сам себя не приведет к изменению кода на вашем локальном компьютере. Вы можете проверить это, когда вы обновляете код, извлекая его после извлечения и просмотра; код он не изменится. Затем вы слились ... Вы увидите измененный код.
Попытка быть ясной и простой.
Команда git pull на самом деле предназначена shortcut
для git-fetch, за которой следует слияние git или команда git rebase в зависимости от вашей конфигурации. Вы можете настроить свой репозиторий Git так, чтобы git pull - выборка, за которой следует rebase.
Фактически Git поддерживает копию вашего собственного кода и удаленного репозитория.
Команда git fetch
обновляет локальную копию, получая данные из удаленного репозитория. Причина, по которой мы нуждаемся в этом, - это то, что кто-то другой мог внести некоторые изменения в код, и вы хотите сохранить себя обновленным.
Команда git pull
приносит изменения в удаленном репозитории, где вы храните свой собственный код. Обычно git pull
это делается с помощью «git fetch», чтобы обновить локальную копию удаленного репозитория, а затем слияние изменений в ваш собственный репозиторий кода и, возможно, вашу рабочую копию.
Это интерактивное графическое представление очень полезно при понимании git: http://ndpsoftware.com/git-cheatsheet.html
git fetch
просто «загружает» изменения с удаленного компьютера на локальный репозиторий. git pull
загружает изменения и объединяет их в вашу текущую ветку. «В режиме по умолчанию git pull
является сокращением для git fetch
за которым следует git merge FETCH_HEAD
».
Единственное различие между git pull
и git fetch
заключается в том, что:
git pull
вытаскивает из удаленной ветви и объединяет ее.
git fetch
только извлекает из удаленной ветви, но не сливается
т.е. git pull = git fetch + git merge ...
Разницу между 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-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 pull = git fetch + git merge