У чым розніца паміж 'git pull' і 'git fetch'?

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

Якія адрозненні паміж git pull і git fetch ?

10500
15 нояб. зададзены pupeno 15 лістапада. 2008-11-15 12:51 '08 у 12:51 2008-11-15 00:51
@ 46 адказаў
  • 1
  • 2

У найпростых тэрмінах git pull выконваецца а 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 00: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 00: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 для получения последнего кода на вашем локальном компьютере. В противном случае локальный машинный код не будет изменен без слияния.