Каква е разликата между "git pull" и "git fetch"?

Бележка на модератора. Като се има предвид, че шестдесет и седем отговора вече са изпратени на този въпрос (някои от тях са изтрити), помислете дали добавяте нещо ново, преди да изпратите друг.

Какви са разликите между git pull и git fetch ?

10500
15 нояб. set pupeno 15 ноември. 2008-11-15 12:51 '08 в 12:51 2008-11-15 12:51
@ 46 отговора
  • 1
  • 2

В най-простия смисъл git pull изпълнява git fetch последвано от git merge .

Можете да направите git fetch по всяко време, за да актуализирате клоновете за дистанционно проследяване в refs/remotes/<remote>/ .

Тази операция никога не променя никое от вашите местни клонове в refs/heads и е безопасно, без да се променя работното копие. Дори чух, че хората периодично пускат git fetch във фонов режим (въпреки че не бих го препоръчал).

А git pull е това, което ще направите, за да актуализирате локалния клон с вашата отдалечена версия, както и да обновите други клонове за дистанционно проследяване.

Git документация: Git дръпнете

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 в 10:23 ч. 2010-05-07 22:23

Трябваше малко да разбера каква е разликата, но това е просто обяснение. master в локалния ви хост е клон.

Когато клонирате хранилище, получавате цялото хранилище за локалния хост. Това означава, че в този момент имате начална / главна показалка на HEAD и главният указател към същата HEAD .

когато започнете да работите и правите това, прехвърляте главния указател на HEAD + вашите фиксации. Но указателят за начало / капитан все още показва какво е било, когато сте клонирани.

Така разликата ще бъде:

  • Ако стартирате git fetch , той просто ще извлече всички промени в отдалеченото хранилище ( GitHub ) и ще премести началния / главния указател на HEAD . Междувременно вашият локален съветник за клонове ще продължи да посочва къде се намира.
  • Ако го направите, ще извлечете (както бе обяснено по-рано) и ще слее всички нови промени в основния клон и ще премести показалеца на HEAD .
347
11 мая '12 в 21:37 2012-05-11 21:37 отговорът е даден на Херардо на 11 май '12 в 21:37 ч. 2012-05-11 21:37

Понякога визуалната презентация помага.

2019

25 янв. отговорът е даден от новия пътник 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 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 .

====

UPDATE

Мислех, че го актуализирам, за да покажа как сте го използвали на практика.

  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.04 2013-04-13 20:31 '13 в 20:31 2013-04-13 20:31
 git-pull - извличане от и сливане с друго хранилище или локален клон Кратък обзор git pull ... ОПИСАНИЕ Стартира git-fetch  извадени глави в текущия клон.  С --rease, извиква git-rebase  вместо git-stop. Обърнете внимание, че можете да използвате.  (текущата директория) като <репозитория> за изтегляне  от местното хранилище - това е полезно, когато се сливат местните клонове  в текущия клон. Също така имайте предвид, че варианта, предназначени за Git-дръпнете себе си и основната Git Разделяне  за git-fetch.

Ако искаш историите да се сливат, ще получиш, ако просто "искаш кода", защото някои от тях поставят тук някои статии.

161
15 нояб. Отговор от Винко Врсалович 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 отговорът е даден от Антонио Бардаци 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 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 февр. отговорът е даден на 6 февруари. 2015-02-06 14:48 '15 в 14:48 2015-02-06 14:48

Е , тук има информация за git pull и git fetch , така че можете да разберете действителните разлики ... с няколко прости думи, извличането получава най-новите данни, но не променя кода и няма да се свърже с текущия код на местния клон, но изважда кода с промените и я обединете в местния си клон, като прочетете, за да получите по-подробна информация за всеки от тях:

git fetch

Тя ще изтегли всички връзки и обекти и всички нови клонове в местното хранилище ...

Изберете клонове и / или тагове (заедно, "refs") от един или повече други хранилища, заедно с обектите, необходими за завършване на техните истории. Актуализирани клонове за дистанционно проследяване (вижте Описание по-долу за начини за контролиране на това поведение).

По подразбиране всеки маркер, който сочи към извлечени истории, също се извлича; ефектът е да извлечете тагове, които сочат към клоновете, които ви интересуват. Това поведение по подразбиране може да бъде променено с помощта на опциите - тагове или --no-тагове или чрез задаване на отдалеченото ..tagOpt. Използвайки refspec, който изрично извлича тагове, можете да извлечете тагове, които не сочат към клоновете, които ви интересуват.

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

Ако не е посочено отдалечено устройство, се използва началният източник по подразбиране, освен ако не е конфигуриран клон за текущия клон.

Имената на връзките, които са избрани, заедно с имената на обектите, към които те сочат, се записват в.git / FETCH_HEAD. Тази информация може да се използва от скриптове или други git команди, като git-pull.


git pull

Той ще приложи промени от отдалечен до настоящ клон в локалния ...

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

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

трябва да бъде името на отдалеченото хранилище, предавано на git-fetch 1 . може да извика произволен отдалечен реф. (например име на етикет) или дори колекция от връзки с съответни клонове за дистанционно проследяване (например refs / heads /: refs / remotes / origin /), но обикновено това е името на клона в отдалеченото хранилище.

Стойностите по подразбиране за и се четат от конфигурациите за "отдалечено" и "сливане" за текущия клон, както е зададено от git-branch --track.


Също така създавам визуално изображение по-долу, за да ви покажа как git fetch и git pull заедно работят ...

2019

бонус:

Като говорим за разтягане и извличане на горните отговори, бих искал да споделя интересен трик,

git pull --rebase

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

Преди да натискате нови съобщения към сървъра, опитайте тази команда и тя автоматично ще синхронизира последните промени в сървъра (използвайки fetch + spelge) и ще постави съобщението ви в началото в git log. Не е нужно да се притеснявате за ръчното изтегляне / сливане.

Намерете информация на адрес : http://gitolite.com/git-pull--remase

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. 

Някои от основните ползи от наличието на огледален образ на конзолата са:

  • Производителност (превъртане на всички съобщения и съобщения, без да се опитва да го компресира през мрежата)
  • Обратна връзка за състоянието на Вашето местно РЕПО (например, използвам 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 в 7:43 pm 2012-07-17 19:43

Разликата между GIT Fetch и GIT Pull може да се обясни със следния сценарий: (Спомняйки си, че снимките говорят по-силно от думите!

Да предположим, че работите по проект с членове на вашия екип. По този начин те ще бъдат едно от главните подразделения на проекта и всички участници трябва да се разделят в собственото си местно хранилище и след това да работят върху този местен клон, за да променят / добавят модули и след това да се върнат в основния клон.

Така че, първоначалното състояние на двата клона, когато изхвърлите основния проект в местното хранилище, ще бъде такова - ( A , B и C са модулите, които вече са завършени в проекта)

2019

07 февр. Отговорът е даден от Aman Tiwari 07 Feb. 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 для получения последнего кода на вашем локальном компьютере. В противном случае локальный машинный код не будет изменен без слияния.