Бонус:

Говоря о 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 .

====

ОБНОВИТЬ

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

1. Обновите локальное репо с удаленного устройства (но не объединяйтесь):

   git fetch

2. После загрузки обновлений, давайте посмотрим различия:

   git diff master origin / master

3. Если вы довольны этими обновлениями, слейте:

   git pull

Заметки:

На шаге 2: более подробно о различиях между локальными и удаленными устройствами см.: Сравнить локальную ветвь git с удаленной ветвью?

На шаге 3: Вероятнее всего, это будет более точным (например, при быстром изменении репо), чтобы здесь происходить git rebase origin . См. Комментарий @Justin Ohms в другом ответе.

См. Также: longair.net/blog/2009/04/16/git-fetch-and-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 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