Koks skirtumas tarp „git pull“ ir „git fetch“?

Moderatoriaus pastaba. Atsižvelgiant į tai, kad šiam klausimui jau buvo išsiųsti šešiasdešimt septyni atsakymai (kai kurie iš jų buvo ištrinti), apsvarstykite, ar prieš pridėdami kitą, pridedate kažką naujo .

Kokie yra skirtumai tarp „ git pull ir „ git fetch ?

10,500
15 нояб. set pupeno 15 nov. 2008-11-15 12:51 '08, 12:51, 2008-11-15 12:51
@ 46 atsakymai
  • 1
  • 2

Paprasčiausiai terminai „ git pull atlieka „ git fetch o po to - „ git merge .

Galite bet kada git fetch kad atnaujintumėte nuotolinio stebėjimo šakas refs/remotes/<remote>/ .

Ši operacija niekada nekeičia jokių vietinių filialų refs/heads galuose ir yra saugi, nekeičiant darbo kopijos. Aš net girdėjau, kad žmonės periodiškai paleidžia git fetch į crono darbą fone (nors aš to nepatarčiau).

git pull yra tai, ką darytumėte, kad atnaujintumėte vietinį filialą su nuotoline versija, taip pat atnaujintumėte kitus nuotolinio stebėjimo filialus.

„Git“ dokumentacija: „ Git“ traukimas

8755
15 нояб. Greg Hewgill atsakymas lapkričio 15 d 2008-11-15 12:52 '08, 12:52 2008-11-15 12:52
  • Kai naudojate pull , „Git“ automatiškai bando atlikti jūsų darbą. Tai yra kontekstui jautri , todėl „Git“ sujungs bet kokį spaudimą, padarytą į filialą, kuriame šiuo metu dirbate. pull automatiškai susilieja, nesiimdama jų pirmiausia . Jei nesate labai gerai valdydami savo filialus, gali kilti dažni konfliktai.

  • Kai fetch , „Git“ surenka visus įsipareigojimus iš tikslinio filialo, kurie nėra jūsų dabartiniame filiale, bet saugomi vietinėje saugykloje . Tačiau jis nesuderinamas su jūsų dabartiniu filialu . Tai ypač naudinga, jei reikia nuolat atnaujinti savo saugyklą, bet dirbti su tuo, kas gali sulūžti, jei atnaujinsite failus. Norint integruoti, jūs įsipareigojate prisijungti prie pagrindinio filialo.

border=0
1919 m
18 авг. Mouna Cheikhna atsakymas 18 rug . 2011-08-18 11:53 '11, 11:53, 2011-08-18 11:53

Svarbu kontrastuoti git dizaino filosofiją su labiau tradicinio šaltinio valdymo įrankio, pvz., SVN, filosofija.

„Subversion“ buvo sukurta ir sukurta naudojant kliento / serverio modelį. Yra viena saugykla, kuri yra serveris, ir keli klientai gali išgauti kodą iš serverio, dirbti su juo ir tada perkelti jį atgal į serverį. Manoma, kad klientas visada gali susisiekti su serveriu, kai jam reikia atlikti operaciją.

„Git“ buvo sukurtas siekiant paremti labiau paskirstytą modelį be centrinės duomenų saugyklos (nors jūs galite ją naudoti, jei norite). Be to, git buvo sukurtas taip, kad klientas ir „serveris“ tuo pačiu metu neturėtų būti prisijungę. „Git“ buvo sukurtas taip, kad nepatikimos nuorodos žmonės netgi galėtų keistis kodu el. Paštu. Galite visiškai išjungti darbą ir įrašyti kompaktinį diską, kad pakeistumėte kodą per git.

Norėdami paremti šį modelį, git palaiko vietinę saugyklą su jūsų kodu, taip pat papildomą vietinę saugyklą, atspindinčią nuotolinio saugyklos būklę. Saugodami nuotolinio saugyklos kopiją vietoje, git gali nustatyti reikalingus pakeitimus, net jei nuotolinė saugykla nėra prieinama. Vėliau, kai reikia išsiųsti pakeitimus kitam asmeniui, git gali juos persiųsti kaip pakeitimų rinkinį iš nuotolinio saugyklos žinomo laiko.

  • git fetch yra komanda, kuri sako: „Iki šiol atnešė mano vietinę nuotolinio saugyklos kopiją“.

  • git pull sako: „Pakeiskite nuotolinio saugyklos pakeitimus, kur laikau savo kodą“.

Paprastai „ git pull “ tai atlieka vykdydama „ git fetch kad atnaujintų vietinės nuotolinio saugyklos kopiją, ir tada sujungti pakeitimus į savo kodų saugyklą ir galbūt jūsų darbo kopiją.

Atminkite, kad jūsų darbo vietoje dažnai yra bent trys projekto kopijos . Viena kopija yra jūsų saugykla, turinti savo pačių įvykių istoriją. Antroji kopija yra jūsų darbo kopija, kurioje redaguojate ir kuriate. Trečioji kopija yra vietinė „talpykloje“ esanti nuotolinio saugyklos kopija.

1066
31 марта '13 в 21:43 2013-03-31 21:43 atsakymą pateikė MikeD kovo 31 d. 13 val. 21:43 2013-03-31 21:43
711
09 июня '15 в 16:30 2015-06-09 16:30 atsakymas pateikiamas Contango birželio 09-15 dienomis 16.30 val. 2015-06-09 16:30

Vienas iš „ git fetch yra tai, kad po paskutinio traukimo bus pranešta apie visus nuotolinio filialo pakeitimus, kad prieš atlikdami faktinį traukimą galite patikrinti, kas gali pakeisti jūsų dabartinio filialo failus ir paleisti kopiją .

 git fetch git diff ...origin 
437
07 мая '10 в 22:23 2010-05-07 22:23 atsakymas pateikiamas mepsterio gegužės 07 d., 10 val. 22:23 val. 2010-05-07 22:23

Turėjau šiek tiek suprasti, koks buvo skirtumas, tačiau tai yra paprastas paaiškinimas. master jūsų vietinėje vietoje yra filialas.

Klonuodami saugyklą, gausite visą vietinio kompiuterio saugyklą. Tai reiškia, kad šiuo metu turite pradinį / pagrindinį rodyklę ant HEAD ir kapitoną nukreipdami į tą patį HEAD .

kai pradėsite dirbti ir tai padarysite, perkeliate pagrindinį rodyklę į HEAD + savo įrašus. Tačiau kilmė / pagrindinis rodiklis vis dar nurodo, kas buvo klonavus.

Taigi skirtumas bus toks:

  • Jei paleisite „ git fetch , jis tiesiog išskirs visus nuotolinio saugyklos pakeitimus („ GitHub“ ) ir perkelia pradžios / pagrindinio rodyklę į HEAD . Tuo tarpu vietinis padalinio vedlys ir toliau nurodys, kur jis yra.
  • Jei git pull , tai iš esmės git pull (kaip paaiškinta anksčiau) ir sujungė visus naujus pakeitimus į pagrindinį šaką ir perkelkite žymiklį į HEAD .
347
11 мая '12 в 21:37 2012-05-11 21:37 atsakymas duotas Gerardo gegužės 11, 12 dienomis 21:37 2012-05-11 21:37

Kartais padeda vizualinis pristatymas.

2019

25 янв. atsakymas pateikiamas 25- iojo sausio mėn . 2016-01-25 20:28 '16 at 8:28 pm 2016-01-25 20:28

trumpai

git fetch yra panašus į pull bet nesilieja. t.y. jis ištraukia nuotolinius naujinimus ( refs ir objects ), bet jūsų vietinis lieka nepakitęs (t.y., origin/master atnaujinamas, bet master lieka tas pats).

git pull nukrenta iš konsolės ir iškart sujungia.

Daugiau

git clone klonų repo.

git rebase išsaugo medžiagą iš jūsų dabartinio filialo, kuris nėra laikinojoje zonoje. Dabar jūsų gija yra tokia pati kaip prieš pradedant pakeitimus. Taigi, „ git pull -rebase ištrintus pakeitimus, git pull -rebase jūsų vietinį padalinį, pakartosite pakeitimus dabartinės šakos viršuje po vieną, kol neatsiliksite nuo naujausių pokyčių.

Be to, git branch -a parodys tiksliai tai, kas vyksta su visais savo filialais - vietiniais ir nuotoliniais.

Šis dienoraščio įrašas buvo naudingas:

Skirtumas tarp „git pull“, „git fetch“ ir „git“ klono (ir „git rebase“) - Mike Pierce

ir apima git pull , git fetch , git clone ir git rebase .

====

UPDATE

Maniau, kad ją atnaujinsiu ir parodau, kaip jūs iš tikrųjų jį naudojote.

  1. Atnaujinkite vietinį repo iš nuotolinio įrenginio (tačiau nesujungkite):

     git fetch 
  2. Atsisiuntus naujinimus, žr. Skirtumus:

     git diff master origin/master 
  3. Jei esate patenkintas šiais naujinimais, sujunkite:

     git pull 

Pastabos:

2 veiksme: Norėdami gauti daugiau informacijos apie skirtumus tarp vietinių ir nuotolinių įrenginių, žr. Skyrių: Kaip palyginti vietinį git filialą su nuotoliniu filialu?

3 veiksme: greičiausiai tai yra tikslesnė (pavyzdžiui, sparčiai besikeičiančioje repo), kad git rebase origin būtų git rebase origin . Žr. @Justin Ohms Komentuoti kitą atsakymą.

Taip pat žiūrėkite: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

170
13 апр. Atsakyti Snowcrash balandžio 13 2013-04-13 20:31 '13, 8:31 pm 2013-04-13 20:31
 git-pull - atsiimti ir sujungti su kita saugykla arba vietiniu filialu SINOPSIS git ... APRAŠYMAS Veikia git-fetch  atkurtas galvos (-ų) į dabartinį filialą.  Su --rebase, skambina git-rebase  vietoj git-suliejimo. Atminkite, kad galite naudoti.  (dabartinis katalogas) kaip „saugykla“, kurią norite traukti  iš vietos saugyklos - tai naudinga jungiant vietines filialus  į dabartinį skyrių. Git-pull  už git-fetch.

Jei norite, kad pasakojimai būtų sujungti, jūs pateksite, jei „tiesiog norėtumėte kodo“, nes kai kurie iš jų įdėjo keletą straipsnių.

161
15 нояб. Vinko Vrsalovic atsakymas lapkričio 15 d 2008-11-15 12:52 '08, 12:52 2008-11-15 12:52

Galite ištraukti iš nuotolinio saugyklos, pamatyti skirtumus ir tada traukti arba sujungti.

Tai nuotolinio saugyklos, pavadintos origin ir filialas, vadinamas master , pavyzdys, kuris seka nuotolinės origin/master filialo:

 git checkout master git fetch git diff origin/master git rebase origin master 
147
21 марта '11 в 14:07 2011-03-21 14:07 atsakymą pateikė Antonio Bardazzi kovo 11 d., 14:07 2011-03-21 14:07

Trumpas ir paprastas atsakymas yra tas, kad „ git pull yra tik git fetch o po to - git merge .

Labai svarbu pažymėti, kad „ git pull automatiškai sujungia, ar jums tai patinka, ar ne . Tai, žinoma, gali sukelti konfliktų sujungimą. Tarkime, kad jūsų konsolė yra origin ir jūsų filialas yra master . Jei prieš traukdami esate git diff origin/master , turėtumėte žinoti apie galimus sujungimo konfliktus ir atitinkamai pasiruošti vietiniam skyriui.

Be traukimo ir paspaudimo, kai kurios darbo eigos apima „ git rebase , pvz., Tai, kurią parafraziu iš susijusio straipsnio:

 git pull origin master git checkout foo-branch git rebase master git push origin foo-branch 

Jei atsidursite šioje situacijoje, jums gali būti gundomas „ git pull --rebase . Jei tikrai nežinote, ką darote, patarčiau tai padaryti. Tai įspėjimas iš „ git-pull versijos 2.3.5 pateikto man puslapio:

Tai yra potencialiai pavojingas veikimo būdas. Jis perrašo istoriją, kuri nėra geras, kai jau paskelbėte šią istoriją. Nenaudokite šio parametro, jei atidžiai neperskaitėte git-rebase (1).

139
15 мая '11 в 23:53 2011-05-15 23:53 atsakymą pateikė jfmercer gegužės 15 d., 11 val. 23:53 2011-05-15 23:53

2019

117
06 февр. atsakymas pateikiamas trisdešimt 06 vasario mėn. 2015-02-06 14:48 '15 at 14:48 2015-02-06 14:48

Na , čia yra šiek tiek informacijos apie „ git pull and git fetch , kad galėtumėte suprasti faktinius skirtumus ... keliais paprastais žodžiais, parsisiunčia naujausius duomenis, tačiau nekeičia kodo ir nesiruošia susisiekti su dabartiniu vietiniu filialo kodu, bet ištraukite kodą su pakeitimais ir sujungti ją į savo vietinį skyrių, skaitykite toliau, jei norite gauti išsamesnės informacijos apie kiekvieną:

git atnešti

Jis parsisiųs visas nuorodas ir objektus bei visus naujus filialus į jūsų vietos saugyklą ...

Iš vienos ar kelių kitų saugyklų pasirinkite filialus ir (arba) žymes (kartu „refs“), taip pat objektus, būtinus jų istorijoms užbaigti. Atnaujinti nuotolinio stebėjimo filialai (žr. Toliau pateiktą aprašymą, kaip valdyti šį elgesį).

Pagal numatytuosius nustatymus bet koks žymeklis, rodantis išgautas istorijas, taip pat atkuriamas; poveikis yra ištraukti žymes, kurios nurodo filialus, kuriuos domina. Šis numatytasis elgesys gali būti pakeistas naudojant parinktis - tags arba --no žymes arba nustatant nuotolinį. Naudodami „refspec“, kuri aiškiai išskiria žymes, galite išskirti žymes, kurios nėra nukreiptos į jus dominančius filialus.

„git fetch“ galima gauti iš vieno pavadinto saugyklos ar URL, arba iš kelių saugyklų vienu metu, jei yra, ir yra konsolių. rašykite į konfigūracijos failą. (Žr. Git-config 1 ).

Jei nenurodytas nuotolinis įrenginys, naudojamas numatytasis pradinis šaltinis, nebent esamos šakos konfigūravimas yra numatytas.

Pasirinktų nuorodų pavadinimai kartu su objektų, į kuriuos jie nurodomi, pavadinimai įrašomi į git / FETCH_HEAD. Šią informaciją gali naudoti scenarijai arba kitos git komandos, pvz., Git-pull.


git traukti

Jis pritaikys pakeitimus iš nuotolinio į esamą filialą vietiniuose ...

Įtraukiami pakeitimai iš nuotolinio saugyklos į esamą filialą. Numatytu režimu „git pull“ yra „git“ atsiuntimo santrumpa, po kurios seka „Git“ sujungimas FETCH_HEAD.

Konkrečiau kalbant, „git pull“ git atsiunčia su nurodytais parametrais ir kviečia „git“ sujungti, kad sujungtų gautas šakų antraštes į dabartinį filialą. Naudojant „rebase “, jis atlieka„ git rebase “, o ne„ git “susijungimą.

turėtų būti nuotolinio saugyklos pavadinimas, perduotas į git-fetch 1 . gali skambinti savavališku nuotoliniu (pvz., žymos pavadinimu) arba netgi nuorodų rinkiniu su atitinkamais nuotolinio stebėjimo filialais (pvz., refs / heads /: refs / remotes / origin /), tačiau paprastai tai yra filialo pavadinimas nuotolinėje saugykloje.

Numatytosios reikšmės ir yra skaitomos iš dabartinės šakos „nuotolinio“ ir „sujungimo“ konfigūracijų, nustatytų git-branch --track.


Aš taip pat sukursiu vaizdinį vaizdą, kad galėtume parodyti, kaip git fetch ir git pull dirbti kartu ...

2019

21 июня '17 в 12:48 2017-06-21 12:48 atsakymą Alireza pateikė birželio 21 d. 17 val. 12:48 2017-06-06 12:48

Premija:

Kalbėdamas apie pirmiau pateiktus atsakymus, norėčiau pasidalinti įdomiu triuku,

git pull --rebase

Ši viršutinė komanda yra naudingiausia komanda mano git gyvenime, kuris išgelbėjo daug laiko.

Prieš stumdami naujus įsipareigojimus serveriui, išbandykite šią komandą ir ji automatiškai sinchronizuos naujausius serverio pakeitimus (naudodama „fetch + merge“) ir įkelkite pranešimą į pradžios žurnalo pradžią. Nereikia nerimauti dėl rankų traukimo / sujungimo.

Rasti informaciją adresu: http://gitolite.com/git-pull--rebase

113
23 дек. Atsakymą pateikė Sazzad Hissain Khan gruodžio 23 d. 2015-12-23 18:31 '15, 18:31, 2015-12-23 18:31

Man patinka turėti tam tikrą vaizdinę situacijos vaizdą, kad galėčiau suprasti šiuos dalykus. Galbūt kiti kūrėjai taip pat norėtų tai pamatyti, todėl čia yra mano papildymas. Nesu visiškai tikras, kad viskas yra teisinga, todėl prašome komentuoti, jei radote klaidų.

  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. 

Kai kurie pagrindiniai konsolės veidrodinio vaizdo privalumai yra šie:

  • Našumas (slenkant visus įsipareigojimus ir pranešimus nesistengiant suspausti per tinklą)
  • Atsiliepimai apie jūsų vietos repo statusą (pvz., Naudoju „Atlassian SourceTree“, kuri suteiks man lemputę, nurodant, ar aš eisiu į priekį ar atgal, palyginti su šaltiniu. Atnaujinkite su GIT FETCH).
107
20 февр. Atsakymą pateikė Justus Romijn , vasario 20 d. 2014-02-20 00:18 '14 at 0:18 2014-02-20 00:18

Aš taip pat kovojau su tuo. Tiesą sakant, čia aš turėjau „Google“ paieškos tą patį klausimą. Perskaičius visus šiuos atsakymus, aš galų gale nupiešiau nuotrauką, ir aš nusprendžiau pabandyti išspręsti 2 saugyklų ir 1 smėlio dėžės būseną ir veiksmus, atliktus su laiku, žiūrėdamas jų versiją. Taigi, ką aš atėjau. Prašome ištaisyti mane, jei aš sujaučiau.

Trys saugyklos su pavyzdžiu:

 --------------------- ----------------------- ----------------------- - 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+ - --------------------- ----------------------- ----------------------- 

Trys saugyklos su apkrova

 --------------------- ----------------------- ----------------------- - 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+ - --------------------- ----------------------- ----------------------- 

Tai padėjo suprasti, kodėl mėginių ėmimas yra labai svarbus.

95
17 июля '12 в 19:43 2012-07-17 19:43 atsakymas pateikiamas pn1 dude liepos 17 d. 12 val. 19.43 val. 2012-07-17 19:43

Skirtumą tarp „ GIT Fetch“ ir „ GIT Pull“ galima paaiškinti šiuo scenarijumi: (Atminkite, kad nuotraukos kalba garsiau nei žodžiai! Pateikiau grafinį vaizdą)

Tarkime, kad dirbate su savo komandos nariais. Taigi jie bus vienas iš pagrindinių projekto padalinių, o visi dalyviai turi suskirstyti savo vietinėje saugykloje, o tada dirbti su šiuo vietiniu padaliniu, kad pakeistų / papildytų modulius, o tada grįžtų į pagrindinį skyrių.

Taigi, pradinė dviejų filialų būklė, kai iškirsite pagrindinį projektą savo vietinėje saugykloje, bus tokia - ( A , B ir C yra jau užbaigti moduliai)

2019

07 февр. Atsakymą pateikė Aman Tiwari 07 vasaris. 2017-02-07 17:15 '17, 17:15 pm 2017-02-07 17:15

Mes tiesiog sakome:

 git pull == git fetch + git merge 

Jei paleisite „ git pull , nereikia sujungti duomenų su vietiniais duomenimis. Jei paleisite „ git fetch , tai reiškia, kad turite paleisti „ git merge kad galėtumėte gauti naujausią kodą vietiniame kompiuteryje. Priešingu atveju vietinis aparato kodas nebus pakeistas be sujungimo.

Taigi, „Git Gui“, atlikdami pavyzdį, turite sujungti duomenis. Ištraukus sau, vietinio kompiuterio kodas nebus pakeistas. Galite patikrinti, kad atnaujindami kodą, išgavę ir peržiūrėję mėginius; kodą jis nekeičia. Tada derinate ... Pamatysite pakeistą kodą.

79
ответ дан Selvamani 21 февр. '13 в 16:25 2013-02-21 16:25

git fetch выводит код с удаленного сервера на ваши ветки отслеживания в локальном репозитории. Если ваш пульт называется origin (по умолчанию), то эти ветки будут находиться в пределах origin/ , например origin/master , origin/mybranch-123 и т.д. Это не ваши текущие ветки, они являются локальными копиями этих ветвей из сервер.

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

77
ответ дан Michael Durrant 19 сент. '13 в 23:01 2013-09-19 23:01

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

73
ответ дан ntanase 27 нояб. '12 в 0:58 2012-11-27 00:58

„Git“ parsisiuntimas