У чому різниця між 'git pull' і 'git fetch'?

Примітка модератора. З огляду на, що на це питання вже було відправлено шістдесят сім відповідей (деякі з них були видалені), подумайте, чи не вносите ви що-небудь нове перед відправкою іншого.

Які відмінності між git pull і git fetch ?

10500
15 нояб. заданий pupeno 15 нояб. 2008-11-15 12:51 '08 о 12:51 2008-11-15 12:51
@ 46 відповідей
  • 1
  • 2

У найпростіших термінах git pull виконується a git fetch , за яким слід git merge .

Ви можете зробити git fetch в будь-який час, щоб оновити гілки віддаленого відстеження в refs/remotes/<remote>/ .

Ця операція ніколи не зраджує жодного з ваших власних локальних гілок в refs/heads і безпечна без зміни робочої копії. Я навіть чув про те, що люди періодично запускають git fetch в завданні cron в фоновому режимі (хоча я б не рекомендував це робити).

A git pull - це те, що ви зробили б, щоб оновити локальну гілка за допомогою своєї віддаленої версії, а також оновити інші гілки віддаленого відстеження.

Git документація: Git pull

8755
15 нояб. відповідь дан Greg Hewgill 15 нояб. 2008-11-15 12:52 '08 о 12:52 2008-11-15 12:52
  • Коли ви використовуєте pull , Git намагається автоматично виконати вашу роботу за вас. Це контекстно-залежна, тому Git об'єднає будь-які виштовхують коммітов в гілку, в якій ви зараз працюєте. pull автоматично об'єднує коммітов, не дозволяючи вам спочатку переглянути їх, Якщо ви не дуже добре керуєте своїми гілки, ви можете зіткнутися з частими конфліктами.

  • Коли ви fetch , Git збираєте будь-які коммітов з цільової гілки, які не існують у вашій поточної гілці, а зберігає їх у вашому локальному сховищі. Однак він не об'єднує їх з вашої поточної гілкою. Це особливо корисно, якщо вам потрібно постійно оновлювати свій репозиторій, але працюйте над тим, що може зламатися, якщо ви відновите свої файли. Щоб інтегрувати коммітов в основну гілку, ви використовуєте merge .

border=0
1919
18 авг. відповідь дан Mouna Cheikhna 18 Серпня. 2011-08-18 11:53 '11 о 11:53 2011-08-18 11:53

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

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

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

Для підтримки цієї моделі git підтримує локальний репозиторій з вашим кодом, а також додатковий локальний репозиторій, який відображає стан віддаленого сховища. Зберігаючи копію віддаленого сховища локально, git може визначити зміни, необхідні, навіть якщо віддалений репозиторій недоступний. Пізніше, коли вам потрібно відправити зміни комусь іншому, git може передати їх як набір змін з моменту часу, відомого віддаленого сховища.

  • git fetch - це команда, яка говорить: "Довести мою локальну копію віддаленого сховища до дати".

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

Зазвичай git pull робить це, виконуючи git fetch щоб оновити локальну копію віддаленого сховища, а потім об'єднати зміни в свій власний репозиторій коду і, можливо, вашу робочу копію.

Прибрати це, щоб мати на увазі, що на вашій робочій станції часто не менше трьох копій проекту. Один екземпляр - це ваш власний репозиторій зі своєю власною історією фіксації. Друга копія - це ваша робоча копія, де ви редагуєте і будуєте. Третя копія - це ваша локальна "кешована" копія видаленого сховища.

1066
31 марта '13 в 21:43 2013-03-31 21:43 відповідь дан MikeD 31 березня '13 о 21:43 2013-03-31 21:43
711
09 июня '15 в 16:30 2015-06-09 16:30 відповідь дан Contango 09 червня '15 о 16:30 2015-06-09 16:30

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

 git fetch git diff ...origin 
437
07 мая '10 в 22:23 2010-05-07 22:23 відповідь дан mepster 07 травня '10 о 22:23 2010-05-07 22:23

Мені коштувало трохи зрозуміти, в чому різниця, але це просте пояснення. master в вашому localhost є гілка.

Коли ви клонуєте репозиторій, ви отримуєте весь репозиторій для локального хоста. Це означає, що в цей час у вас є вказівник origin / master на HEAD і майстер, який вказує на той же HEAD .

коли ви починаєте працювати, і робите це, ви переводите покажчик майстра на HEAD + ваші фіксації. Але покажчик origin / master все ще вказує на те, що було, коли ви клонували.

Таким чином, різниця буде:

  • Якщо ви виконаєте git fetch , він просто отримає всі зміни в віддаленому репозиторії ( GitHub ) і перемістіть початок / майстер-покажчик на HEAD . Тим часом ваш майстер локального гілки буде продовжувати вказувати, де він знаходиться.
  • Якщо ви виконаєте git pull , він буде виконувати в основному витяг (як пояснювалося раніше) і об'єднати будь-які нові зміни в основну гілку і перемістити покажчик на HEAD .
347
11 мая '12 в 21:37 2012-05-11 21:37 відповідь дан Gerardo 11 травня '12 о 21:37 2012-05-11 21:37

Іноді візуальне уявлення допомагає.

2019

25 янв. відповідь дан thedarkpassenger 25 Січня. 2016-01-25 20:28 '16 о 20:28 2016-01-25 20:28

коротко

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/

170
13 апр. відповідь дан Snowcrash 13 Квітня. 2013-04-13 20:31 '13 о 20:31 2013-04-13 20:31
 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.

Ви б потягнули, якщо хочете, щоб історії злилися, ви б отримали, якби ви просто "хотіли код", оскільки хтось із них поміщав деякі статті тут.

161
15 нояб. відповідь дан Vinko Vrsalovic 15 нояб. 2008-11-15 12:52 '08 о 12:52 2008-11-15 12:52

Ви можете отримати з віддаленого сховища, побачити відмінності, а потім витягнути або об'єднати.

Це приклад віддаленого сховища з ім'ям origin і гілкою з ім'ям master , що відстежує віддалену гілку origin/master :

 git checkout master git fetch git diff origin/master git rebase origin master 
147
21 марта '11 в 14:07 2011-03-21 14:07 відповідь дан Antonio Bardazzi 21 березня '11 о 14:07 2011-03-21 14:07

Короткий і проста відповідь полягає в тому, що 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).

139
15 мая '11 в 23:53 2011-05-15 23:53 відповідь дан jfmercer 15 травня '11 о 23:53 2011-05-15 23:53

2019

117
06 февр. відповідь дан th3sly 06 февр. 2015-02-06 14:48 '15 о 14:48 2015-02-06 14:48

Добре, ось деякі відомості про git pull і git fetch , тому ви можете зрозуміти фактичні відмінності ... кількома простими словами, fetch отримує останні дані, але не змінює код і не збирається зв'язуватися з вашим поточним кодом локальної гілки, але витягніть код зі змінами і об'єднайте його в свою локальну гілка, прочитайте далі, щоб отримати більш детальну інформацію про кожного:

git fetch

Він буде завантажувати всі посилання і об'єкти і будь-які нові гілки в ваш локальний репозиторій ...

Вибирайте гілки і / або теги (разом, "refs") з одного або декількох інших репозиторіїв разом з об'єктами, необхідними для завершення їх історій. Оновлені гілки віддаленого відстеження (див. Опис нижче для способів контролю цієї поведінки).

За замовчуванням також витягується будь тег, який вказує на витягнуті історії; ефект полягає в тому, щоб витягувати теги, що вказують на ваші гілки. Це поведінка за умовчанням можна змінити за допомогою опцій --tags або --no-tags або шляхом настройки remote..tagOpt. Використовуючи refspec, який явно витягує теги, ви можете отримувати теги, які не вказують на ваші гілки.

git fetch може вилучатись з одного іменованого сховища або URL-адреси або з декількох репозитаріїв відразу, якщо дано, і є пульти. запис в файл конфігурації. (Див. Git-config 1 ).

Якщо не вказано жодного віддаленого пристрою, за замовчуванням використовується пусковий джерело, якщо тільки гілка висхідного потоку не налаштована для поточної гілки.

Імена посилань, які обрані, разом з іменами об'єктів, на які вони вказують, записуються в.git / FETCH_HEAD. Ця інформація може використовуватися скриптами або іншими командами git, такими як git-pull.


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 працюють разом ...

2019

бонус:

Говорячи про витягуванні і витяганні в наведених вище відповідях, я хотів би поділитися цікавим трюком,

git pull --rebase

Ця вищенаведена команда є найкориснішою командою в моєму житті git, яка заощадила багато часу.

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

Знайти інформацію за адресою: http://gitolite.com/git-pull--rebase

113
23 дек. відповідь дан Sazzad Hissain Khan 23 дек. 2015-12-23 18:31 '15 о 18:31 2015-12-23 18:31

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

  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. with the origin  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. repo  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. 

Деякі основні переваги наявності дзеркального відображення пульта:

  • Продуктивність (прокрутка всіх коммітов і повідомлень, не намагаючись стиснути її через мережу)
  • Зворотній зв'язок про стан вашого локального репо (наприклад, я використовую Atlassian SourceTree, який дасть мені лампочку, яка вказує, чи буду я йти вперед або назад в порівнянні з джерелом. Оновити за допомогою GIT FETCH).
107
20 февр. відповідь дан Justus Romijn 20 февр. 2014-02-20 00:18 '14 в 0:18 2014-02-20 00:18

Я теж боровся з цим. Насправді я потрапив сюди з пошуком 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+ - --------------------- ----------------------- ----------------------- 

Це допомогло мені зрозуміти, чому вибірка дуже важлива.

95
17 июля '12 в 19:43 2012-07-17 19:43 відповідь дан pn1 dude 17 липня '12 о 19:43 2012-07-17 19:43

Різницю між GIT Fetch і GIT Pull можна пояснити наступним сценарієм: (Пам'ятаючи, що картинки говорять голосніше слів!, Я надав графічне представлення)

Давайте припустимо, що ви працюєте над проектом з членами вашої команди. Таким чином, їх буде одним з основних підрозділів проекту, і всі учасники повинні разветкіть його в своєму власному локальному репозиторії, а потім працювати над цим локальним філією, щоб змінити / додати модулі, а потім повернутися до основної гілки.

Отже, початковий стан двох гілок, коли ви розгалужується основний проект в своєму локальному репозиторії, буде як this- ( A , B і C - це модулі, вже завершені в проекті)

2019

07 февр. відповідь дан Aman Tiwari 07 февр. 2017-02-07 17:15 '17 о 17:15 2017-02-07 17:15

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

 git pull == git fetch + git merge 

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