Wat zijn de verschillen tussen git pullen git fetch?

---

Antwoord 1, autoriteit 100%

In de eenvoudigste bewoordingen doet git pulleen git fetchgevolgd door een git merge.

Je kunt op elk moment een git fetchdoen om je remote tracking branches bij te werken onder refs/remotes/<remote>/. Deze operatie verandert nooit je eigen lokale vestigingen onder refs/heads, en is veilig om te doen zonder je werkkopie te wijzigen. Ik heb zelfs gehoord van mensen die periodiek git fetchuitvoeren in een cronjob op de achtergrond (hoewel ik dit niet zou aanraden).

Een git pullis wat je zou doen om een ​​lokale branch up-to-date te brengen met zijn remote versie, terwijl je ook je andere remote-tracking branches bijwerkt.

Van de Git-documentatie voor git pull:

In de standaardmodus is git pulleen afkorting voor git fetchgevolgd door git merge FETCH_HEAD.

---

Antwoord 2, autoriteit 22%

• Als je pullgebruikt, probeert Git automatisch samen te voegen. Het is contextgevoelig, dus Git zal alle getrokken commits samenvoegen in de branch waar je momenteel aan werkt. pullvoegt automatisch de commits samen zonder dat je ze eerst hoeft te bekijken. Als u uw filialen niet zorgvuldig beheert, kunt u regelmatig conflicten tegenkomen.

• Als je fetch, verzamelt Git alle commits van de doelbranch die niet bestaan ​​in je huidige branch en slaat ze op in je lokale repository. Echter, het voegt ze niet samen met je huidige branch. Dit is vooral handig als u uw repository up-to-date moet houden, maar aan iets werkt dat zou kunnen breken als u uw bestanden bijwerkt. Om de commits in je huidige branch te integreren, moet je daarna mergegebruiken.

---

Antwoord 3, autoriteit 12%

Het is belangrijk om de ontwerpfilosofie van git te contrasteren met de filosofie van een meer traditionele broncontroletool zoals SVN.

Subversion is ontworpen en gebouwd met een client/server-model. Er is een enkele repository die de server is en verschillende clients kunnen code van de server ophalen, eraan werken en deze vervolgens terug naar de server vastleggen. De veronderstelling is dat de client altijd contact kan opnemen met de server wanneer deze een bewerking moet uitvoeren.

Git is ontworpen om een ​​meer gedistribueerd model te ondersteunen zonder dat er een centrale repository nodig is (hoewel je er zeker een kunt gebruiken als je wilt). Git is ook zo ontworpen dat de client en de “server” niet tegelijkertijd online hoeven te zijn. Git is zo ontworpen dat mensen op een onbetrouwbare link zelfs via e-mail code kunnen uitwisselen. Het is mogelijk om volledig losgekoppeld te werken en een CD te branden om code uit te wisselen via git.

Om dit model te ondersteunen, onderhoudt git een lokale repository met uw code en ook een extra lokale repository die de status van de externe repository weerspiegelt. Door lokaal een kopie van de externe repository te bewaren, kan git de benodigde wijzigingen achterhalen, zelfs wanneer de externe repository niet bereikbaar is. Later, wanneer je de wijzigingen naar iemand anders moet sturen, kan git ze als een set wijzigingen overdragen vanaf een bekend tijdstip naar de externe repository.

• git fetchis het commando dat zegt “breng mijn lokale kopie van de externe repository up-to-date.”

• git pullzegt “breng de wijzigingen in de externe repository naar waar ik mijn eigen code bewaar.”

Normaal gesproken doet git pulldit door een git fetchuit te voeren om de lokale kopie van de externe repository te brengen up-to-date te houden en vervolgens de wijzigingen samen te voegen in uw eigen coderepository en mogelijk uw werkkopie.

Het voordeel is om in gedachten te houden dat er vaak minstens drie exemplarenvan een project op uw werkstation staan. Eén exemplaar is je eigen repository met je eigen commit-geschiedenis. Het tweede exemplaar is je werkkopie waar je aan het bewerken en bouwen bent. Het derde exemplaar is uw lokale “gecachte” kopie van een externe repository.

---

Antwoord 4, autoriteit 9%

Hier is Oliver Steele’s afbeelding van hoe het allemaal in elkaar past:

Als er voldoende interesse is, zou ik de afbeelding kunnen bijwerken om git cloneen git mergetoe te voegen…

---

Antwoord 5, autoriteit 5%

Een use case van git fetchis dat het volgende je alle veranderingen in de remote branch sinds je laatste pull zal vertellen… in je huidige branch en werkkopie.

git fetch
git diff ...origin

Zie: https://git-scm.com/docs/git-diffbetreffende de dubbele en driedubbele puntsyntaxis in het diff-commando

---

Antwoord 6, autoriteit 4%

Het kostte me een beetje om te begrijpen wat het verschil was, maar dit is een eenvoudige uitleg. masterin uw localhost is een branch.

Als je een repository kloont, haal je de hele repository op naar je lokale host. Dit betekent dat je op dat moment een origin/master pointer naar HEADhebt en master die naar dezelfde HEADwijst.

wanneer je begint te werken en commits doet, ga je de master pointer naar HEAD+ je commits. Maar de oorsprong/hoofdaanwijzer wijst nog steeds naar wat het was toen je kloonde.

Het verschil is dus:

• Als je een git fetchdoet, worden alle wijzigingen in de externe repository opgehaald (GitHub) en verplaats de oorsprong/master-aanwijzer naar HEAD. Ondertussen zal je lokale filiaalmeester blijven wijzen naar waar hij is.
• Als je een git pulldoet, zal het in principe fetch doen (zoals eerder uitgelegd) en alle nieuwe wijzigingen in je master branch mergen en de aanwijzer naar HEADverplaatsen.

---

Antwoord 7, autoriteit 2%

Kort

git fetchlijkt op pullmaar voegt niet samen. dwz het haalt externe updates op (refsen objects) maar uw lokale blijft hetzelfde (dwz origin/masterwordt bijgewerkt maar masterblijft hetzelfde).

git pulltrekt naar beneden vanaf een afstandsbediening en voegt onmiddellijk samen.

Meer

git clonekloont een repo.

git rebasebewaart dingen van je huidige branch die niet in de upstream branch staan ​​naar een tijdelijk gebied. Uw branch is nu hetzelfde als voordat u uw wijzigingen startte. Dus git pull -rebasezal de externe wijzigingen verwijderen, je lokale branch terugspoelen, je wijzigingen één voor één opnieuw afspelen over de top van je huidige branch totdat je up-to-date bent.

Bovendien zal git branch -aje precies laten zien wat er aan de hand is met al je branches – lokaal en op afstand.

Deze blogpost was nuttig:

Het verschil tussen git pull, git fetch en git clone (en git rebase) – Mike Pearce

en omvat git pull, git fetch, git cloneen git rebase.

UPDATE

Ik dacht dat ik dit zou bijwerken om te laten zien hoe je dit in de praktijk zou gebruiken.

1. Update uw lokale repo vanaf de afstandsbediening (maar niet samenvoegen):

   git fetch 
   

2. Laten we na het downloaden van de updates eens kijken naar de verschillen:

   git diff master origin/master 
   

3. Als je tevreden bent met die updates, voeg dan samen:

   git pull
   

Opmerkingen:

Bij stap 2: Zie voor meer informatie over verschillen tussen lokaal en extern: Hoe vergelijk je een lokale git branch met zijn remote branch?

Bij stap 3: Het is waarschijnlijk nauwkeuriger (bijvoorbeeld bij een snel veranderende repo) om hier een git rebase originte doen. Zie @Justin Ohms opmerkingin nog een antwoord.

Zie ook: http://longair.net/ blog/2009/04/16/git-fetch-and-merge/

---

Antwoord 8, autoriteit 2%

Soms helpt een visuele weergave.

---

Antwoord 9, autoriteit 2%

git-pull - Ophalen van en samenvoegen met een andere repository of een lokale branch
KORTE INHOUD
git pull  
OMSCHRIJVING
Voert git-fetch uit met de gegeven parameters, en roept git-merge aan om de . samen te voegen
opgehaalde kop(pen) in de huidige vertakking. Met --rebase, roept git-rebase
in plaats van git-merge.
Merk op dat u kunt gebruiken. (huidige map) als de <repository> trekken
uit de lokale repository  dit is handig bij het samenvoegen van lokale branches
in de huidige vestiging.
Merk ook op dat opties bedoeld zijn voor git-pull zelf en onderliggende git-merge
moet worden gegeven vóór de opties bedoeld voor git-fetch.

Je zou pullen als je wilt dat de geschiedenissen worden samengevoegd, je zou halen als je gewoon ‘de codez wilt’, aangezien iemand hier een aantal artikelen heeft getagd.

---

Antwoord 10, autoriteit 2%

Je kunt ophalen uit een externe repository, de verschillen bekijken en vervolgens pullen of samenvoegen.

Dit is een voorbeeld voor een externe repository genaamd originen een branch genaamd masterdie de remote branch origin/mastervolgt:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

---

Antwoord 11, autoriteit 2%

Het korte en gemakkelijke antwoord is dat git pullsimpelweg git fetchis, gevolgd door git merge.

Het is erg belangrijk op te merken dat git pullautomatisch zal samenvoegen, of je het nu leuk vindt of niet. Dit kan natuurlijk leiden tot fusieconflicten. Laten we zeggen dat uw afstandsbediening originis en dat uw branch masteris. Als je git diff origin/mastervoordat je gaat pullen, zou je enig idee moeten hebben van mogelijke merge conflicten en zou je je lokale branch dienovereenkomstig kunnen voorbereiden.

Naast trekken en duwen, sommige workflowsomvatten git rebase, zoals deze, die ik parafraseer uit het gelinkte artikel:

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

Als u zich in een dergelijke situatie bevindt, kunt u in de verleiding komen om git pull --rebasete gebruiken. Tenzij je echt, echt weet wat je doet, zou ik dat afraden. Deze waarschuwing komt van de man-pagina voor git-pull, versie 2.3.5:

Dit is een potentieel gevaarlijke manier van werken. Het herschrijft
geschiedenis, wat niet veel goeds voorspelt toen je die geschiedenis publiceerde
nu al. Gebruik deze optie niet tenzij je git-rebase(1) hebt gelezen
voorzichtig.

---

Antwoord 12, autoriteit 2%

OK, hier is wat informatie over git pullen git fetch, zodat je de werkelijke verschillen kunt begrijpen… in een paar simpele woorden, fetchhaalt de laatste gegevens op, maar niet de codewijzigingen en gaat niet rotzooien met uw huidige lokale filiaalcode, maar pullhaal de codewijzigingen op en voeg deze samen met uw lokale branch, lees verder voor meer details over elk:

git fetch

Het zal alle refsen objectenen alle nieuwe branches downloaden naar je lokale repository…

Vertakkingen en/of tags (gezamenlijk “refs”) ophalen van een of meer
andere repositories, samen met de objecten die nodig zijn om hun
geschiedenissen. Vertakkingen voor het op afstand volgen zijn bijgewerkt (zie de beschrijving
van hieronder voor manieren om dit gedrag te beheersen).

Standaard is elke tag die verwijst naar de op te halen geschiedenis
ook opgehaald; het effect is om tags op te halen die verwijzen naar takken die
waarin u geïnteresseerd bent. Dit standaardgedrag kan worden gewijzigd door gebruik te maken van
de –tags of –no-tags opties of door te configureren
afstandsbediening..tagOpt. Door een refspec te gebruiken die tags expliciet ophaalt,
je kunt tags ophalen die niet verwijzen naar branches waarin je geïnteresseerd bent
ook binnen.

git fetch kan ophalen van een enkele benoemde repository of URL of
uit meerdere repositories tegelijk als is gegeven en er is a
afstandsbedieningen. vermelding in het configuratiebestand. (Zie git-config1).

Als er geen afstandsbediening is opgegeven, is de oorspronkelijke afstandsbediening standaard
gebruikt, tenzij er een stroomopwaartse tak is geconfigureerd voor de huidige
filiaal.

De namen van refs die worden opgehaald, samen met de objectnamen
ze verwijzen naar, zijn geschreven naar .git/FETCH_HEAD. Deze informatie kan zijn:
gebruikt door scripts of andere git-commando’s, zoals git-pull.

---

git pull

Het zal de wijzigingen van remotetoepassen op de huidige vertakkingin de lokale…

Incorporeert wijzigingen van een externe repository in de huidige branch.
In de standaardmodus is git pull een afkorting voor git fetch gevolgd door
git merge FETCH_HEAD.

Precies, git pull voert git fetch uit met de gegeven parameters en
roept git merge aan om de opgehaalde branch heads samen te voegen met de current
tak. Met –rebase wordt git rebase uitgevoerd in plaats van git merge.

moet de naam zijn van een externe repository zoals doorgegeven aan
git-fetch1. kan een willekeurige externe ref een naam geven (bijvoorbeeld
de naam van een tag) of zelfs een verzameling refs met bijbehorende
vertakkingen volgen op afstand (bijv. refs/heads/:refs/remotes/origin/),
maar meestal is het de naam van een branch in de remote repository.

Standaardwaarden voor en worden gelezen van de
“remote” en “merge” configuratie voor de huidige branch zoals ingesteld door
git-branch –track.

---

Ik maak ook de visualhieronder om je te laten zien hoe git fetchen git pullsamenwerken…

---

Antwoord 13

Deze interactieve grafische weergave is erg handig om git te begrijpen: http://ndpsoftware.com/git-cheatsheet.html

git fetch“downloadt” gewoon de wijzigingen van de remote naar je lokale repository. git pulldownloadt de wijzigingen en voegt ze samen in je huidige branch. “In de standaardmodus is git pulleen afkorting voor git fetchgevolgd door git merge FETCH_HEAD.”

---

Antwoord 14

Bonus:

Over pull & haal de bovenstaande antwoorden op, ik wil graag een interessante truc delen,

git pull --rebase

Dit bovenstaande commando is het meest bruikbare commando in mijn git-leven dat veel tijd heeft bespaard.

Voordat je je nieuwe commits naar de server pusht, probeer deze opdracht en het zal automatisch de laatste serverwijzigingen synchroniseren (met een fetch + merge) en je commit bovenaan in git log plaatsen. U hoeft zich geen zorgen te maken over handmatig trekken/samenvoegen.

Vind details op: http://gitolite.com/git-pull–rebase

---

Antwoord 15

Ik heb graag een visuele weergave van de situatie om deze dingen te begrijpen. Misschien willen andere ontwikkelaars het ook zien, dus hier is mijn toevoeging. Ik ben er niet helemaal zeker van dat het allemaal juist is, dus geef alsjeblieft een reactie als je fouten vindt.

                                        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.

Enkele grote voordelen van het hebben van een opgehaalde spiegel van de afstandsbediening zijn:

• Prestaties(scroll door alle commits en berichten zonder te proberen het door het netwerk te persen)
• Feedbackover de staat van uw lokale repo (ik gebruik bijvoorbeeld de SourceTree van Atlassian, die me een lamp geeft die aangeeft of ik commits voor of achter ben in vergelijking met de oorsprong. Deze informatie kan worden bijgewerkt met een GIT FETCH).

---

Antwoord 16

Het verschil tussen GIT Fetchen GIT Pullkan worden verklaard met het volgende scenario:
(Houd er rekening mee dat foto’s meer zeggen dan woorden!, ik heb een picturale weergave gegeven)

Laten we een voorbeeld nemen dat u met uw teamleden aan een project werkt. Er zal dus één hoofdtak van het project zijn en alle bijdragers moeten het naar hun eigen lokale repository gaan en vervolgens aan deze lokale tak werken om modules te wijzigen/toe te voegen en vervolgens terug te duwen naar de hoofdtak.

Dus,
Initiële staatvan de twee filialen toen u het hoofdproject op uw lokale repository forkeerde, zal als volgt zijn: (A, Ben Czijn reeds voltooide modules van het project)

Nu ben je begonnen met het werken aan de nieuwe module (stel D) en wanneer je de Dmodule hebt voltooid, wil je deze naar de hoofdtak pushen, maar wat er ondertussen gebeurt, is dat een van je teamgenoten de nieuwe module E, Fen Cheeft aangepast.
Wat er nu is gebeurd, is dat uw lokale repository achterloopt op de oorspronkelijke voortgang van het project en dat het pushen van uw wijzigingen naar de hoofdbranch tot conflicten kan leiden en ervoor kan zorgen dat uw Module Dniet goed werkt.

Om dergelijke problemen te vermijden en parallel aan de oorspronkelijke voortgang van het project te werken, zijn er twee manieren:

1. Git Fetch-Dit zal alle wijzigingen downloaden die zijn aangebracht in het origin/main branch-project die niet aanwezig zijn in uw lokale branch. En zal wachten tot het Git Merge-commando de wijzigingen toepast die zijn opgehaald naar uw repository of branch.

Dus nu kun je de bestanden zorgvuldig in de gaten houden voordat je ze samenvoegt met je repository. En u kunt indien nodig ook Dwijzigen vanwege Modified C.

2. Git Pull-Dit zal je lokale branch updaten met de origin/main branch, d.w.z. wat het eigenlijk doet is een combinatie van Git Fetch en Git merge de een na de ander.
Maar dit kan leiden tot conflicten, dus het wordt aanbevolen om Git Pull te gebruiken met een schone kopie.

---

Antwoord 17

Ik heb hier ook mee geworsteld. In feite kwam ik hier met een Google-zoekopdracht van precies dezelfde vraag. Toen ik al deze antwoorden las, kreeg ik uiteindelijk een beeld in mijn hoofd en ik besloot dit te proberen te achterhalen, kijkend naar de staat van de 2 repositories en 1 sandbox en acties die in de loop van de tijd werden uitgevoerd terwijl ik de versie ervan bekeek. Dus hier is wat ik bedacht. Corrigeer me als ik ergens een fout heb gemaakt.

De drie repo’s met een fetch:

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

De drie repo’s met een pull

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

Dit heeft me geholpen te begrijpen waarom een ​​ophaalactie erg belangrijk is.

---

Antwoord 18

We zeggen gewoon:

git pull == git fetch + git merge

Als je git pulluitvoert, hoef je de gegevens niet samen te voegen met lokaal. Als je git fetchuitvoert, betekent dit dat je git mergemoet uitvoeren om de laatste code op je lokale computer te krijgen. Anders zou de lokale machinecode niet worden gewijzigd zonder samenvoeging.

Dus in de Git Gui, als je ophaalt, moet je de gegevens samenvoegen. Fetch zelf zal de code niet wijzigen bij uw lokale. U kunt dat controleren wanneer u de code bijwerkt door op te halen
een keer halen en zien; de code zal het niet veranderen. Dan voeg je samen… Je ziet de gewijzigde code.

---

Antwoord 19

git fetchhaalt de code van de externe server naar je tracking-takken in je lokale repository. Als uw afstandsbediening de naam originheeft (de standaardinstelling), dan bevinden deze vertakkingen zich binnen origin/, bijvoorbeeld origin/master, origin/mybranch-123, etc. Dit zijn niet je huidige branches, het zijn lokalekopieën van die branches van de server.

git pulldoet een git fetchmaar dan ookvoegt de code van de tracking branch samen met je huidige lokale versie van die branch. Als je nog niet klaar bent voor die veranderingen, gewoon git fetcheerst.

---

Antwoord 20

git fetchzal remote branches ophalen zodat je ze kunt git diffof git mergemet de huidige branch. git pullzal fetch uitvoeren op de remote brach die wordt gevolgd door de huidige branch en vervolgens het resultaat samenvoegen. Je kunt git fetchgebruiken om te zien of er updates zijn voor de remote branch zonder dat je ze hoeft te mergen met je lokale branch.

---

Antwoord 21

In eenvoudige bewoordingen, als je op het punt stond om op een vliegtuig te stappen zonder internetverbinding…voor vertrek zou je gewoon git fetch origin <branch>kunnen doen. Het zou alle wijzigingen in uw computer ophalen, maar het gescheiden houden van uw lokale ontwikkel-/werkruimte.

In het vliegtuig kunt u wijzigingen aanbrengen in uw lokale werkruimte en deze vervolgens samenvoegen met wat u eerder hebt opgehaald en vervolgens mogelijke samenvoegconflicten oplossen, allemaal zonder een verbinding met internet. En tenzij iemand nieuwewijzigingen heeft aangebracht in de externe repository, dan zou je, zodra je op de bestemming bent aangekomen, git push origin <branch>doen en je koffie gaan halen.

---

Van deze geweldige Atlassian-zelfstudie:

Het git fetchcommando downloadt commits, bestanden en refs van a
externe repository in uw lokale repository.

Ophalen is wat je doet als je wilt zien wat iedereen andersheeft
aan gewerkt. Het is vergelijkbaar met SVN-update omdat het je laat zien
hoe de centrale geschiedenis is gevorderd, maar het dwingt je niet tot
voeg de wijzigingen daadwerkelijk samen in uw repository. Git isoleert
inhoud heeft opgehaald als een van bestaande lokale inhoud, het heeft absoluut
geen effect op uw lokale ontwikkelingswerk. Opgehaalde inhoud moet expliciet worden uitgecheckt met behulp van de opdracht git checkout. Dit maakt
een veilige manier ophalen om commits te bekijken voordat je ze integreert met
uw lokale opslagplaats.

Bij het downloaden van inhoud van een externe repository zijn git pullen git fetchcommando’s beschikbaar om de taak uit te voeren. Je kunt overwegen:
git fetchde ‘veilige’ versie van de twee commando’s. Het zal downloaden
de externe inhoud, maar werk de werkstatus van uw lokale repository niet bij,
uw huidige werk intact laten. git pullis de meer agressieve
alternatief, het zal de externe inhoud downloaden voor de actieve lokale
branch en voer onmiddellijk git mergeuit om een ​​merge commit te maken
voor de nieuwe externe inhoud. Als er wijzigingen in behandeling zijn
dit zal conflicten veroorzaken en de oplossing voor het samenvoegen van conflicten starten
stromen.

---

Met git pull:

• Je krijgt geen isolatie.
• Het hoeft niet expliciet te worden uitgecheckt. Omdat het impliciet een git mergedoet.
• De samenvoegingsstap heeft invloed op uw lokale ontwikkeling en kanconflicten veroorzaken
• Het is in principe NIET veilig. Het is agressief.
• In tegenstelling tot git fetchwaar het alleen je .git/refs/remotesbeïnvloedt, heeft git pull invloed op zowel je .git/refs/remotesen.git/refs/heads/

---

Hmmm…dus als ik de werkkopie niet bijwerk met git fetch, waar breng ik dan wijzigingen aan? Waar haalt Git de nieuwe commits op?

Goede vraag. Eerst en vooral slaan de headsof remotesde nieuwe commits niet op. Ze hebben alleen aanwijzingente plegen. Dus met git fetchdownload je de nieuwste git-objecten(blob, tree, commits. Bekijk deze video over git internals< om de objecten volledig te begrijpen), maar werk alleen je remotespointer bij om naar de laatste commit van die branch te wijzen. Het is nog steeds geïsoleerd van je werkkopie, omdat de aanwijzer van je branch in de headsdirectory niet is bijgewerkt. Het wordt alleen bijgewerkt na een merge/pull. Maar nogmaals waar? Laten we het uitzoeken.

In je projectdirectory (d.w.z. waar je je git-opdrachten doet) doe je:

1. ls. Dit toont de bestanden & mappen. Niets cools, ik weet het.

2. Doe nu ls -a. Dit toont dot-bestanden, dwz bestanden die beginnen met .U zult dan een map kunnen zien met de naam: .git.

3. Doe cd .git. Dit zal uiteraard je directory veranderen.

4. Nu komt het leuke gedeelte; doe ls. U ziet een lijst met mappen. We zijn op zoek naar refs. Doe cd refs.

5. Het is interessant om te zien wat er in alle mappen staat, maar laten we ons concentreren op twee ervan. headsen remotes. Gebruik cdom er ook in te kijken.

6. Elkegit fetchdie je doet, zal de aanwijzer in de /.git/refs/remotesdirectory bijwerken. Het zal niets in de /.git/refs/headsdirectory bijwerken.

7. Elkegit pullzal eerst de git fetchdoen, items bijwerken in de /.git/refs/remotesdirectory, voeg dan samen met je local en verander dan de head in de /.git/refs/headsdirectory.

---

Een zeer goed gerelateerd antwoord is ook te vinden in Waar plaatst ‘git fetch’ zichzelf?.

Zoek ook naar “Slash-notatie” in de Git-tak naamgevingsconventiesbericht. Het helpt je beter te begrijpen hoe Git dingen in verschillende mappen plaatst.

---

Om het werkelijke verschil te zien

Doe gewoon:

git fetch origin master
git checkout master

Als de externe master is bijgewerkt, krijgt u een bericht als dit:

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Als je niet fetchhebt gedaan en gewoon git checkout masterhebt gedaan, dan zou je lokale git niet weten dat er 2 commits zijn toegevoegd. En het zou gewoon zeggen:

Already on 'master'
Your branch is up to date with 'origin/master'.

Maar dat is achterhaald en onjuist. Het is omdat git je alleen feedback geeft op basis van wat het weet. Het is zich niet bewust van nieuwe commits die het nog niet heeft afgebroken…

---

Is er een manier om de nieuwe wijzigingen op afstand te zien terwijl je lokaal aan de branch werkt?

Sommige IDE’s (bijv. Xcode) zijn super slim en gebruiken het resultaat van een git fetchen kunnen de regels code annoteren die zijn gewijzigd in de remote branch van je huidige werkende branch. Als die regel is gewijzigd door zowel lokale wijzigingen als een vertakking op afstand, wordt die regel rood geannoteerd. Dit is geen samenvoegconflict. Het is een mogelijksamenvoegconflict. Het is een headsup die je kunt gebruiken om het toekomstige merge conflict op te lossen voordat je git pulldoet vanuit de remote branch.

---

Leuke tip:

Als je een externe tak hebt opgehaald, b.v. deed:

git fetch origin feature/123

Dan komt dit in je remotes directory. Het is nog steeds niet beschikbaar in uw lokale directory. Het vereenvoudigt echter het afrekenen naar die externe vestiging via DWIM (Doe wat ik bedoel):

git checkout feature/123

u hoeft niet langer het volgende te doen:

git checkout -b feature/123 origin/feature/123

Lees voor meer informatie hier

---

Antwoord 22

Git Fetch

Je downloadt wijzigingen naar je lokale vestiging vanaf de oorsprong via fetch. Fetch vraagt ​​de externe repo naar alle commits die anderen hebben gemaakt, maar die je niet hebt op je lokale repo. Fetch downloadt deze commits en voegt ze toe aan de lokale repository.

Git Samenvoegen

U kunt wijzigingen toepassen die zijn gedownload via fetch met behulp van de merge-opdracht. Merge neemt de commits die uit fetch zijn opgehaald en probeert ze toe te voegen aan je lokale branch. De samenvoeging houdt de vastleggingsgeschiedenis van je lokale wijzigingen bij, zodat wanneer je je branch deelt met push, Git weet hoe anderen je wijzigingen kunnen samenvoegen.

Git Pull

Fetchen en samenvoegen lopen vaak genoeg samen dat een commando dat de twee combineert, pull, is gemaakt. Pull doet een fetch en vervolgens een merge om de gedownloade commits toe te voegen aan je lokale branch.

---

Antwoord 23

Het enige verschil tussen git pullen git fetchis dat:

git pullhaalt uit een remote branch en merget deze.

git fetchhaalt alleen op van de remote branch maar wordt niet samengevoegd

d.w.z. git pull = git fetch + git merge …

---

Antwoord 24

Git staat toe dat chronologisch oudere commits worden toegepast na nieuwere commits.
Hierdoor wordt het overdragen van commits tussen repositories in twee stappen opgesplitst:

1. Nieuwe commits kopiëren van remote branch naar kopie van deze remote branch in lokale repo.

   (repo naar repo-bewerking) master@remote >> remote/origin/master@local

2. Nieuwe toezeggingen integreren in lokale vestiging

   (inside-repo-bewerking) remote/origin/master@local >> master@local

Er zijn twee manieren om stap 2 uit te voeren. U kunt:

1. Fork de lokale branch na de laatste gemeenschappelijke voorouder en voeg nieuwe commits toe parallel aan commits die uniek zijn voor de lokale repository, gefinaliseerd door commit samen te voegen en de fork te sluiten.
2. Voeg nieuwe commits in na de laatste gemeenschappelijke voorouder en pas commits die uniek zijn voor de lokale repository opnieuw toe.

In gitterminologie is stap 1 git fetch, stap 2 is git mergeof git rebase

git pullis git fetchen git merge

---

Antwoord 25

Git verkrijgt de vertakking van de laatste versie van de remote naar de local met behulp van twee commando’s:

1. git fetch: Git haalt de nieuwste versie van extern naar lokaal, maar wordt niet automatisch samengevoegd.
       
   git fetch origin master
git log -p master..origin/master
git merge origin/master

        De bovenstaande commando’s betekenen dat de nieuwste versie van de hoofdbranch van origin van de remote naar de origin masterbranch moet worden gedownload. En vergelijkt vervolgens de lokale master-branch en origin master-branch. Eindelijk samenvoegen.

2. git pull: Git gaat de nieuwste versie van de afstandsbediening halen en samenvoegen met de lokale versie.

      
   git pull origin master

        Het bovenstaande commando is het equivalent van git fetchen git merge. In de praktijk is git fetchmisschien veiliger omdat we vóór het samenvoegen de wijzigingen kunnen zien en kunnen beslissen of we willen samenvoegen.

---

Antwoord 26

Wat is het verschil tussen git pullen git fetch?

Om dit te begrijpen, moet je eerst begrijpen dat je lokale git niet alleen je lokale repository onderhoudt, maar ook een lokale kopie van de remote repository.

git fetchbrengt uw lokale kopie van de externe repository up-to-date. Als uw externe repository bijvoorbeeld GitHub is, wilt u misschien alle wijzigingen die in de externe repository zijn aangebracht, ophalen in uw lokale kopie van de externe repository. Hiermee kunt u bewerkingen uitvoeren zoals vergelijken of samenvoegen.

git pullaan de andere kant zal de wijzigingen in de externe repository terugbrengen naar waar je je eigen code bewaart. Gewoonlijk zal git pulleerst een git fetchdoen om de lokale kopie van de externe repository up-to-date te brengen, en dan zal het de wijzigingen samenvoegen in uw eigen coderepository en eventueel uw werkkopie.

---

Antwoord 27

git pull == ( git fetch + git merge)

git fetch verandert niets aan lokale branches.

Als je al een lokale repository hebt met een externe set-up voor het gewenste project, kun je alle branches en tags voor de bestaande remote pakken met git fetch . … Fetch brengt geen wijzigingen aan in lokale vertakkingen, dus je moet een vertakking op afstand samenvoegen met een gekoppelde lokale vertakking om nieuwe fetch-wijzigingen op te nemen. van github

---

Antwoord 28

Proberen duidelijk en eenvoudig te zijn.

Het git pullcommando is eigenlijk een shortcutvoor git fetchgevolgd door de git mergeof de git rebasecommando afhankelijk van je configuratie. Je kunt je Git-repository zo configureren dat git pulleen fetch is gevolgd door een rebase.

---

Antwoord 29

Een eenvoudige grafische weergave voor beginners,

hier,

git pull  

haalt code op uit de repository en rebaset met je lokale… in git pull is het mogelijk dat er nieuwe commits worden aangemaakt.

maar in ,

git fetch

haalt code op uit de repository en we moeten deze handmatig rebasen met behulp van git rebase

bijvoorbeeld: ik ga ophalen van servermaster en rebase het in mijn lokale master.

1) git pull (rebase wordt automatisch gedaan):

git pull origin master

hier oorsprongis uw externe repo masteris uw branch

2) git fetch (moet handmatig rebasen):

git fetch origin master

het haalt serverwijzigingen op van oorsprong. en het zal in uw lokale zijn totdat u het zelf rebaset. we moeten conflicten handmatig oplossen door codes te controleren.

git rebase origin/master

hiermee wordt de code omgezet in lokaal. zorg ervoor dat u zich in de juiste branche bevindt.

---

Antwoord 30

Eigenlijk onderhoudt Git een kopie van je eigen code en
de externe repository.

Het commando git fetchmaakt je lokale kopie up-to-date door gegevens uit een externe repository te halen. De reden dat we dit nodig hebben, is omdat iemand anders misschien enkele wijzigingen in de code heeft aangebracht en u uzelf op de hoogte wilt houden.

Het commando git pullbrengt de wijzigingen in de externe repository naar waar je je eigen code bewaart. Normaal gesproken doet git pulldit door eerst een git fetch te doen om de lokale kopie van de remote repository up-to-date te brengen, en dan voegt het de wijzigingen samen in je eigen code repository en mogelijk je werkkopie .