Git

git-pull last updated in 2.52.0

NAMN

git-pull - Hämta från och integrera med annat repo eller en lokal gren

SYNOPSIS

git pull [<flaggor>] [<repo> [<refspec>…]]

BESKRIVNING

Integrera ändringar från ett fjärr-repo i den aktuella grenen.

Först kör git pull git fetch med samma argument (exklusive sammanslagningsalternativ) för att hämta fjärrgren(ar). Sedan bestämmer den vilken fjärrgren som ska integreras: om du kör git pull utan argument används som standard upstream för den aktuella grenen. Sedan integreras den grenen i den aktuella grenen.

Det finns fyra huvudalternativ för att integrera fjärrgrenen:

git pull --ff-only kommer bara att göra "snabbspola framåt"-uppdateringar: det misslyckas om din lokala gren har divergerat från fjärrgrenen. Detta är standardinställningen.
git pull --rebase kör git rebase
git pull --no-rebase kör git merge.
git pull --squash kör git merge --squash

Du kan också ställa in konfigurationsalternativen pull.rebase, pull.squash eller pull.ff med ditt föredragna beteende.

Om det uppstår en sammanslagningskonflikt under sammanslagningen eller ombasering som du inte vill hantera, kan du säkert avbryta den med git merge --abort eller git rebase --abort.

ALTERNATIV

<repo>: "Fjärr"-arkivet att hämta från. Detta kan antingen vara en URL (se avsnittet GIT URLS nedan) eller namnet på en fjärrenhet (se avsnittet FJÄRR nedan).

Standardinställningen är den konfigurerade uppströmsfilen för den aktuella grenen, eller origin. Se UPPSTRÖMS-GRENAR nedan för mer information om hur man konfigurerar uppströmsfilar.
<refspec>: Vilken gren eller annan referens(er) som ska hämtas och integreras i den aktuella grenen, till exempel main i git pull origin main. Standardinställningen är den konfigurerade uppström för den aktuella grenen.

Detta kan vara en gren, tagg eller annan samling av referenser. Se <refspec> nedan under "Alternativ relaterade till hämtning" för den fullständiga syntaxen, och STANDARDBETEENDE nedan för hur git pull använder detta argument för att avgöra vilken fjärrgren som ska integreras.
-q
--quiet: Detta skickas till både underliggande git-fetch till kväva rapportering under överföring, och underliggande git-merge för att kväva-utdata under sammanslagning.
-v
--verbose: Skicka --verbose till git-fetch och git-merge.
--recurse-submodules[=(yes|on-demand|no)]
--no-recurse-submodules: Det här alternativet styr om nya incheckningar för ifyllda undermoduler ska hämtas, och om de fungerande träden för aktiva undermoduler också ska uppdateras (se git-fetch[1], git-config[1] och gitmodules[5]).

Om utcheckningen görs via ombasering, ombaseras även lokala undermodul-incheckningar.

Om uppdateringen görs via sammanslagning, löses undermodulkonflikterna och de checkas ut.

Alternativ gällande sammanslagning

--commit
--no-commit: Utför sammanslagningen och spara resultatet. Det här alternativet kan användas för att åsidosätta --no-commit. Endast användbart vid sammanslagning.

Med --no-commit utför du sammanslagnings-funktionen och stoppar den precis innan du skapar en sammanslagnings-incheckning, för att ge användaren en chans att granska och ytterligare justera sammanslagnings-resultatet innan den checkar in.

Observera att snabbspolningsuppdateringar inte skapar en sammanslagins-incheckning och därför finns det inget sätt att stoppa dessa sammanslagningar med --no-commit. Om du vill se till att din gren inte ändras eller uppdateras av sammanslagings-kommandot, använd --no-ff med --no-commit.
--edit
-e
--no-edit: Anropa en editor innan den mekaniska sammanfogningen genomförs för att ytterligare redigera det automatiskt genererade sammanfogningsmeddelandet, så att användaren kan förklara och motivera sammanfogningen. Alternativet --no-edit kan användas för att acceptera det automatiskt genererade meddelandet (detta avråds generellt).

Äldre skript kan bero på det historiska beteendet att inte tillåta användaren att redigera sammanslagningsloggmeddelandet. De kommer att se en editor öppen när de kör git merge. För att göra det enklare att anpassa sådana skript till det uppdaterade beteendet kan miljövariabeln GIT_MERGE_AUTOEDIT sättas till no i början av dem.
--cleanup=<läge>: Det här alternativet avgör hur sammanslagningsmeddelandet ska rensas innan det incheckas. Se git-commit[1] för mer information. Om <läge> dessutom ges värdet scissors, kommer scissors att läggas till i MERGE_MSG innan de skickas vidare till inchecknings-maskineriet i händelse av en sammanslagningskonflikt.
--ff-only: Uppdatera endast till den nya historiken om det inte finns någon avvikande lokal historik. Detta är standardinställningen när ingen metod för att stämma av avvikande historiker tillhandahålls (via flaggorna --rebase).
--ff
--no-ff: Vid sammanslagning snarare än ombasering, anger detta hur en sammanslagning hanteras när den sammanslagna historiken redan är en underordnad del av den aktuella historiken. Om sammanslagning begärs är --ff standardinställningen såvida inte en kommenterad (och eventuellt signerad) tagg som inte lagras på sin naturliga plats i refs/tags/-hierarkin sammanfogas, i vilket fall --no-ff antas.

Med --ff, lös när det är möjligt sammanslagningen som en snabbspolning framåt (uppdatera endast grenpekaren så att den matchar den sammanslagna grenen; skapa inte en merge-commit). När det inte är möjligt (när den sammanslagna historiken inte är en underordnad del av den aktuella historiken), skapa en sammanslagings-incheckning.

Med --no-ff, skapa en sammanslagings-incheckning i alla fall, även när merge istället skulle kunna lösas som en snabbspolning framåt.
-S[<nyckel-id>]
--gpg-sign[=<nyckel-id>]
--no-gpg-sign: GPG-signera den resulterande sammanslagningsincheckningen. Argumentet <nyckel-id> är valfritt och har som standard incheckare-identiteten; om det anges måste det fästas vid alternativet utan mellanslag. --no-gpg-sign är användbart för att negligera både konfigurationsvariabeln commit.gpgSign och den tidigare --gpg-sign.
--log[=<n>]
--no-log: Förutom grennamn, fyll i loggmeddelandet med enradsbeskrivningar från högst <n> faktiska incheckningar som sammanfogas. Se även git-fmt-merge-msg[1]. Endast användbart vid sammanslagning.

Med --no-log listas inte enradsbeskrivningar från de faktiska incheckningar som sammanfogas.
--signoff
--no-signoff: Add a Signed-off-by trailer by the committer at the end of the commit log message. The meaning of a signoff depends on the project to which you’re committing. For example, it may certify that the committer has the rights to submit the work under the project’s license or agrees to some contributor representation, such as a Developer Certificate of Origin. (See https://developercertificate.org for the one used by the Linux kernel and Git projects.) Consult the documentation or leadership of the project to which you’re contributing to understand how the signoffs are used in that project.

Alternativet --no-signoff kan användas för att upphäva ett tidigare --signoff-alternativ på kommandoraden.

Git har inte (och kommer inte ha) en konfigurationsvariabel för att aktivera kommandoradsalternativet --signoff som standard; se commit.signoff-posten i gitfaq[7] för mer information.

--stat
-n
--no-stat: Visa en diffstat i slutet av sammanslagningen. Diffstat styrs också av konfigurationsalternativet merge.stat.

Med -n eller --no-stat visas ingen diffstat i slutet av sammanslagningen.
--compact-summary: Visa en kompakt sammanfattning när sammanslagningen är färdig.
--squash
--no-squash: Skapa arbetsträdet och indextillståndet som om en riktig sammanslagning hade skett (förutom sammanslagningsinformationen), men gör inte en faktisk incheckning, flytta inte HEAD eller registrera $GIT_DIR/MERGE_HEAD (för att få nästa git commit-kommando att skapa en sammanslagnings-incheckning). Detta låter dig skapa en enda incheckning ovanpå den aktuella grenen vars effekt är densamma som att sammanfoga en annan gren (eller fler i fallet med en bläckfisk).

Med --no-squash utförs sammanslagningen och chacka-in resultatet. Detta alternativ kan användas för att åsidosätta --squash.

Med --squash är --commit inte tillåtet och kommer att misslyckas.

Endast användbart vid sammanslagning.
--verify
--no-verify: Som standard, körs pre-merge- och commit-msg-krokarna. När --no-verify anges, kringgås dessa. Se även githooks[5]. Endast användbart vid sammanslagning.
-s <strategi>
--strategy=<strategi>: Använd den givna sammanslagningsstrategin; kan anges mer än en gång för att ange dem i den ordning de ska provas. Om det inte finns något -s-alternativ används en inbyggd lista med strategier istället (ort vid sammanslagning av en enskild rubrik, octopus annars).
-X <alternativ>
--strategy-option=<alternativ>: Skicka det specifika alternativet för sammanslagningsstrategin vidare till sammanslagningsstrategin.
--verify-signatures
--no-verify-signatures: Verifiera att tip incheckningen för sidgrenen som sammanfogas är signerad med en giltig nyckel, d.v.s. en nyckel som har en giltig uid: i standardförtroendemodellen betyder detta att signeringsnyckeln har signerats av en betrodd nyckel. Om tip incheckningen för sidgrenen inte är signerad med en giltig nyckel avbryts sammanfogningen.

Endast användbart vid sammanslagning.
--summary
--no-summary: Synonymer till --stat och --no-stat; dessa är föråldrade och kommer att tas bort i framtiden.
--autostash
--no-autostash: Skapa automatiskt en tillfällig gömma-post innan operationen börjar, registrera den i referensen MERGE_AUTOSTASH och tillämpa den efter att operationen är avslutad. Det betyder att du kan köra operationen på ett smutsigt arbetsträd. Använd dock försiktigt: den slutliga gömma-applikationen efter en lyckad sammanslagning kan resultera i icke-triviala konflikter.
--allow-unrelated-histories: Som standard vägrar git merge-kommandot att slå samman historiker som inte delar en gemensam förfader. Det här alternativet kan användas för att åsidosätta denna säkerhetsåtgärd när man slår samman historiker för två projekt som startade sina liv oberoende av varandra. Eftersom det är ett mycket sällsynt fall finns ingen konfigurationsvariabel för att aktivera detta som standard, och kommer inte att läggas till.

Endast användbart vid sammanslagning.

-r

--rebase[=(true|merges|false|interactive)]

true: Ombasera den aktuella grenen ovanpå den uppströms grenen efter hämtning. Om det finns en fjärrspårningsgren som motsvarar den uppströms grenen och den uppströms grenen har ombaserats sedan den senaste hämtningen, använder ombasen den informationen för att undvika ombasering av icke-lokala ändringar. Detta är standardinställningen.
merges: ombasering med git rebase --rebase-merges så att de lokala sammanslagnings-incheckningar inkluderas i rebasen (se git-rebase[1] för detaljer).
false: sammanfoga den uppströms grenen med den nuvarande grenen.
interactive: aktivera det interaktiva läget för ombasering.

Se pull.rebase, branch.<name>.rebase och branch.autoSetupRebase i git-config[1] om du vill att git pull alltid ska använda --rebase istället för sammanslagning.

Note	Detta är ett potentiellt farligt driftläge. Det skriver om historiken, vilket inte bådar gott när du redan har publicerat den historiken. Använd inte det här alternativet om du inte har läst git-rebase[1] noggrant.

--no-rebase

Detta är en förkortning för --rebase=false.

Alternativ gällande hämtningar

--all
--no-all: Hämta ("fetcha") alla fjärrar, förutom de som har konfigurationsvariabeln remote.<namn>.skipFetchAll angiven. Detta åsidosätter konfigurationsvariabeln fetch.all.
-a
--append: Lägg till referensnamn och objektnamn för hämtade referenser till det befintliga innehållet i .git/FETCH_HEAD. Utan detta alternativ kommer gammal data i .git/FETCH_HEAD att skrivas över.
--atomic: Använd en atomär transaktion för att uppdatera lokala referenser. Antingen uppdateras alla referenser, eller så uppdateras inga referenser vid fel.
--depth=<djup>: Begränsa hämtningen till det angivna antalet incheckningar från toppen av varje fjärrgrenhistorik. Om hämtning sker till ett ytligt-repo (shallow) skapat av git clone med alternativet --depth=<djup> (se git-clone[1]), fördjupa eller förkorta historiken till det angivna antalet incheckningar. Taggar för de fördjupade incheckningar hämtas inte.
--deepen=<djup>: Liknar --depth, förutom att den anger antalet incheckningar från den aktuella ytliga gränsen istället för från toppen av varje fjärrgrenhistorik.
--shallow-since=<datum>: Fördjupa eller förkorta historiken för ett ytligt repo för att inkludera alla nåbara incheckningar efter <datum>.
--shallow-exclude=<ref>: Fördjupa eller förkorta historiken för ett ytligt repo för att exkludera incheckningar som är åtkomliga från en specifik fjärrgren eller tagg. Det här alternativet kan anges flera gånger.
--unshallow: Om käll-repot är komplett, konvertera ett ytligt repo till ett komplett, och ta bort alla begränsningar som ytliga repon medför.

Om käll-repot är ytligt, hämta så mycket som möjligt så att det aktuella repot har samma historik som käll-repot.
--update-shallow: Som standard vid hämtning från ett ytligt repo, vägrar git fetch referenser som kräver uppdatering av .git/shallow. Det här alternativet uppdaterar .git/shallow och accepterar sådana referenser.
--negotiation-tip=(<incheckning>|<glob>): Som standard, rapporterar Git incheckningar till servern som är nåbara från alla lokala referenser för att hitta gemensamma incheckningar i ett försök att minska storleken på den packfil som ska tas emot. Om detta anges kommer Git bara att rapportera incheckningar som är nåbara från de givna tipsen. Detta är användbart för att påskynda hämtningar när användaren vet vilken lokal referens som sannolikt har incheckningar gemensamt med den uppströms referens som hämtas.

Det här alternativet kan anges mer än en gång; om så är fallet kommer Git att rapportera incheckningar som är åtkomliga från vilken som helst av de givna incheckningar.

Argumentet till detta alternativ kan vara en glob på referensnamn, en ref eller (eventuellt förkortad) SHA-1 för en commit. Att ange en glob är liktydigt med att ange detta alternativ flera gånger, en för varje matchande referensnamn.

Se även konfigurationsvariablerna fetch.negotiationAlgorithm och push.negotiate som är dokumenterade i git-config[1], och alternativet --negotiate-only nedan.
--negotiate-only: Hämta ingenting från servern, och skriv istället ut de förfäder till den angivna --negotiation-tip=-argumenten, som vi har gemensamt med servern.

Detta är inkompatibelt med --recurse-submodules=(yes|on-demand). Internt används detta för att implementera alternativet push.negotiate, se git-config[1].
--dry-run: Visa vad som skulle göras, utan att göra några ändringar.
--porcelain: Skriv ut utdata till standardutdata i ett lätttolkat format för skript. Se avsnittet UTMATNING i git-fetch[1] för mer information.

Detta är inkompatibelt med --recurse-submodules=(yes|on-demand) och har företräde framför konfigurationsalternativet fetch.output.
-f
--force: När git fetch används med <src>:<dst> refspec, kan den vägra att uppdatera den lokala grenen vilket diskuteras i <refspec>-delen av git-fetch[1]-dokumentationen. Det här alternativet åsidosätter den kontrollen.
-k
--keep: Behåll hämtade paket.
--prefetch: Ändra den konfigurerade refspec:en för att placera alla referenser i namnrymden refs/prefetch/. Se prefetch-uppgiften i git-maintenance[1].
-p
--prune: Innan du hämtar, ta bort alla referenser till fjärrspårning som inte längre finns på fjärren. Taggar kan inte beskäras om de bara hämtas på grund av standardtaggens automatiska efterföljning eller på grund av ett --tags-alternativ. Men om taggar hämtas på grund av en explicit refspec (antingen på kommandoraden eller i fjärrkonfigurationen, till exempel om fjärren klonades med alternativet --mirror), kan de också beskäras. Att ange --prune-tags är en förkortning för att ange taggens refspec.
--no-tags: Som standard, hämtas och lagras taggar som pekar på objekt som laddas ner från fjärr-repot lokalt. Det här alternativet inaktiverar denna automatiska taggföljningen. Standardbeteendet för en fjärren kan anges med inställningen remote.<namn>.tagOpt. Se git-config[1].
--refmap=<refspec>: När du hämtar referenser som listas på kommandoraden, använd den angivna refspecen (kan anges mer än en gång) för att mappa referenserna till fjärrspårningsgrenar, istället för värdena för remote.<name>.fetch-konfigurationsvariabler för fjärr-repot. Om du anger ett tomt <refspec> till alternativet --refmap ignorerar Git de konfigurerade refspecs och förlitar sig helt på de refspecs som anges som kommandoradsargument. Se avsnittet om "Konfigurerade fjärrspårningsgrenar" för mer information.
-t
--tags: Hämta alla taggar från fjärrkontrollen (dvs. hämta fjärrtaggar refs/tags/* till lokala taggar med samma namn), utöver vad som annars skulle hämtas. Att använda det här alternativet ensamt utsätter inte taggar för beskärning, även om --prune används (även om taggar kan beskäras ändå om de också är destinationen för en explicit refspec; se --prune).
-j <n>
--jobs=<n>: Parallellisera alla former av hämtning upp till <n> jobb åt gången.

Om alternativet --multiple angavs kommer de olika fjärrar att hämtas parallellt. Om flera undermoduler hämtas kommer de att hämtas parallellt. För att styra dem oberoende av varandra, använd konfigurationsinställningarna fetch.parallel och submodule.fetchJobs (se git-config[1]).

Vanligtvis är parallella rekursiva hämtningar och hämtningar från flera fjärrar snabbare. Som standard utförs hämtningar sekventiellt, inte parallellt.
--set-upstream: Om fjärr hämtas korrekt, lägg till en uppströmsreferens (spårningsreferens), som används av argumentlösa git-pull[1] och andra kommandon. För mer information, se branch.<namn>.merge och branch.<namn>.remote i git-config[1].
--upload-pack <upload-pack>: När det anges, och repot att hämta från hanteras av git fetch-pack, skickas --exec=<upload-pack> till kommandot för att ange en icke-standardsökväg för kommandot som körs i andra änden.
--progress: Förloppsstatus rapporteras som standard i standardfelströmmen när den är kopplad till en terminal, såvida inte -q anges. Denna flagga tvingar fram förloppsstatus även om standardfelströmmen inte dirigeras till en terminal.
-o <alternativ>
--server-option=<alternativ>: Skicka den givna strängen till servern vid kommunikation med protokollversion 2. Den givna strängen får inte innehålla tecknet NUL eller LF. Serverns hantering av serveralternativ, inklusive okända, är serverspecifik. När flera --server-option=<alternativ> anges skickas de alla till den andra sidan i den ordning som anges på kommandoraden. När ingen --server-option=<alternativ> anges från kommandoraden används istället värdena för konfigurationsvariabeln remote.<namn>.serverOption.
--show-forced-updates: Som standard kontrollerar git om en branch tvångsuppdateras under hämtning. Detta kan inaktiveras via fetch.showForcedUpdates, men alternativet --show-forced-updates garanterar att denna kontroll sker. Se git-config[1].
--no-show-forced-updates: Som standard kontrollerar git om en gren tvångsuppdateras under hämtning. Skicka --no-show-forced-updates eller sätt fetch.showForcedUpdates till "false" för att hoppa över denna kontroll av prestandaskäl. Om det används under git-pull kommer alternativet --ff-only fortfarande att kontrollera om det finns tvångsuppdateringar innan en snabbuppdatering försöker göras. Se git-config[1].
-4
--ipv4: Använd endast IPv4-adresser och ignorera IPv6-adresser.
-6
--ipv6: Använd endast IPv6-adresser och ignorera IPv4-adresser.

<repo>: Det "fjärrlagrade" repot som är källan för en hämtnings- eller dra-operation (fetch, pull). Denna parameter kan antingen vara en URL (se avsnittet GIT URLS nedan) eller namnet på en fjärren (se avsnittet FJÄRR nedan).

<refspec>

Anger vilka referenser som ska hämtas och vilka lokala referenser som ska uppdateras. När inga <refspec>s visas på kommandoraden läses referenserna som ska hämtas från variablerna remote.<repo>.fetch istället (se avsnittet "KONFIGURERADE FJÄRRSPÅRNINGSGRENAR" i git-fetch[1]).

Formatet för en <refspec>-parameter är ett valfritt plustecken +, följt av källtan <src>, följt av ett kolon :, följt av målet <dst>. Kolonet kan utelämnas när <mål> är tomt. <src> är vanligtvis en referens, eller ett globmönster med ett enda * som används för att matcha en uppsättning referenser, men det kan också vara ett fullständigt stavat hexagonalt objektnamn.

En <refspec> kan innehålla ett * i sin <src> för att indikera en enkel mönstermatchning. En sådan refspec fungerar som en glob som matchar vilken referens som helst med mönstret. En mönster <refspec> måste ha ett och endast ett * i både <src> och <mål>. Den mappar referenser till destinationen genom att ersätta * med innehållet som matchas från källan.

Om en refspec har prefixet ^ kommer den att tolkas som en negativ refspec. Istället för att ange vilka referenser som ska hämtas eller vilka lokala referenser som ska uppdateras, kommer en sådan refspec istället att ange referenser som ska exkluderas. En ref kommer att anses matcha om den matchar minst en positiv refspec och inte matchar någon negativ refspec. Negativa refspecs kan vara användbara för att begränsa omfattningen av en mönsterrefspec så att den inte inkluderar specifika referenser. Negativa refspecs kan själva vara mönsterrefspecs. De får dock bara innehålla en <src> och anger inte en <mål>. Fullständigt stavade hexadecimala objektnamn stöds inte heller.

tag <tagg> betyder samma sak som refs/tags/<tag>:refs/tags/<tagg>; den begär att allt upp till den givna taggen hämtas.

Fjärrreferensen som matchar <src> hämtas, och om <mål> inte är en tom sträng görs ett försök att uppdatera den lokala referensen som matchar den.

Huruvida den uppdateringen är tillåten utan --force beror på referensnamnrymden den hämtas till, typen av objekt som hämtas och om uppdateringen anses vara en snabbspolning framåt. Generellt sett gäller samma regler för hämtning som vid pushing, se avsnittet <refspec>... i git-push[1] för vad dessa är. Undantag från dessa regler som är specifika för git fetch anges nedan.

Fram till Git version 2.20, och till skillnad från när man pushar med git-push[1], skulle alla uppdateringar till refs/tags/* accepteras utan + i refspec (eller --force). Vid hämtning betraktade vi promiskuöst alla tagguppdateringar från en fjärren som tvångshämtningar. Sedan Git version 2.20 fungerar hämtning för att uppdatera refs/tags/* på samma sätt som vid pushing. Dvs. alla uppdateringar kommer att avvisas utan + i refspec (eller --force).

Till skillnad från när man pushar med git-push[1], kommer alla uppdateringar utanför refs/{tags,heads}/* att accepteras utan + i refspec (eller --force), oavsett om det är att byta ut t.ex. ett trädobjekt mot en blob, eller en incheckning mot en annan incheckning som inte har den tidigare incheckning som en förfader etc.

Till skillnad från när man pushar med git-push[1] finns det ingen konfiguration som ändrar dessa regler, och inget som en pre-fetch-krok analog med pre-receive-kroken.

Precis som med pushing med git-push[1], kan alla regler som beskrivs ovan om vad som inte är tillåtet som en uppdatering åsidosättas genom att lägga till ett valfritt inledande + till en refspec (eller genom att använda kommandoradsalternativet --force). Det enda undantaget från detta är att ingen mängd tvång kommer att få namnrymden refs/heads/* att acceptera ett icke-inchecknings-objekt.

Note

När den fjärrgren du vill hämta är känd för att regelbundet spolas tillbaka och ombaseras, förväntas det att dess nya tips inte kommer att vara en underordnad av dess tidigare tips (som lagrats i din fjärrspårningsgren förra gången du hämtade). Du vill använda +-tecknet för att indikera att uppdateringar som inte är framåtspolade kommer att behövas för sådana grenar. Det finns inget sätt att avgöra eller deklarera att en gren kommer att göras tillgänglig i ett arkiv med detta beteende; den indragande ("pullande") användaren måste helt enkelt veta att detta är det förväntade användningsmönstret för en gren.

Note

Det är skillnad på att lista flera <refspec> direkt på git pull-kommandoraden och att ha flera remote.<repo>.fetch-poster i din konfiguration för ett <repo> och att köra ett git pull-kommando utan några explicita <refspec>-parametrar. <refspec>s som listas explicit på kommandoraden slås alltid samman med den aktuella grenen efter hämtning. Med andra ord, om du listar mer än en fjärrreferens, kommer git pull att skapa en bläckfisk-sammanslagning. Å andra sidan, om du inte listar någon explicit <refspec>-parameter på kommandoraden, kommer git pull att hämta alla <refspec>s som den hittar i remote.<repository>.fetch-konfigurationen och slå samman endast den första <refspec> som hittas med den aktuella grenen. Detta beror på att det sällan görs att skapa en bläckfisk från fjärrreferenser, medan det ofta är användbart att hålla reda på flera fjärrreferenser samtidigt genom att hämta mer än ett.

GIT URLS

I allmänhet innehåller URL:er information om transportprotokollet, adressen till fjärrservern och sökvägen till repot. Beroende på transportprotokollet kan en del av denna information saknas.

Git stöder ssh-, git-, http- och https-protokollen (dessutom kan ftp och ftps användas för hämtning, men detta är ineffektivt och föråldrat; använd dem inte).

Den inbyggda transporten (dvs. git:// URL) utför ingen autentisering och bör användas med försiktighet på osäkra nätverk.

Följande syntaxer kan användas med dem:

ssh://[<användare>@]<värd>[:<port>]/<sökväg-till-git-repo>
git://<värd>[:<port>]/<sökväg-till-git-repo>
http[s]://<värd>[:<port>]/<sökväg-till-git-repo>
ftp[s]://<värd>[:<port>]/<sökväg-till-git-repo>

En alternativ scp-liknande syntax kan också användas med ssh-protokollet:

[<användare>@]<värd>[:<port>]/<sökväg-till-git-repo>

Denna syntax känns bara igen om det inte finns några snedstreck före det första kolonet. Detta hjälper till att skilja en lokal sökväg som innehåller ett kolon. Till exempel kan den lokala sökvägen foo:bar anges som en absolut sökväg eller ./foo:bar för att undvika att misstolkas som en ssh-url.

Protokollen ssh och git stöder dessutom ~<username>-expansionen:

ssh://[<användare>@]<värd>[:<port>]/<sökväg-till-git-repo>
git://[<användare>@]<värd>[:<port>]/<sökväg-till-git-repo>
[<användare>@]<värd>[:<port>]/<sökväg-till-git-repo>

För lokala repos, som också stöds nativt av Git, kan följande syntaxer användas:

/sokvag/till/repo.git/
file:///sokvag/till/repo.git/

Dessa två syntaxer är mestadels likvärdiga, förutom vid kloning, då den förra innebär alternativet --local. Se git-clone[1] för detaljer.

git clone, git fetch och git pull, men inte git push, accepterar också en lämplig bundle-fil. Se git-bundle[1].

När Git inte vet hur ett visst transportprotokoll ska hanteras, försöker det använda fjärr-hjälparen remote-<transport>, om en sådan finns. För att explicit begära en fjärr-hjälpare kan följande syntax användas:

<transport>::<adress>

där <adress> kan vara en sökväg, en server och sökväg, eller en godtycklig URL-liknande sträng som känns igen av den specifika fjärrhjälparen som anropas. Se gitremote-helpers[7] för mer information.

Om det finns ett stort antal fjärrdatabaser med liknande namn och du vill använda ett annat format för dem (så att de URL:er du använder skrivs om till URL:er som fungerar), kan du skapa en konfigurationssektion i formatet:

	[url "<faktisk-url-bas>"]
		insteadOf = <annan-url-bas>

Till exempel med detta:

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/sokvag/till/
		insteadOf = arbete:

En URL som "arbete:repo.git" eller "host.xz:/sokvag/till/repo.git" kommer att skrivas om i alla sammanhang som antar att URL:en är "git://git.host.xz/repo.git".

Om du vill skriva om URL:er enbart för sändning (push), kan du skapa en konfigurationssektion i formen:

	[url "<faktisk-url-bas>"]
		pushInsteadOf = <annan-url-bas>

Till exempel med detta:

	[url "ssh://example.org/"]
		pushInsteadOf = git://example.org/

En URL som "git://example.org/path/to/repo.git" kommer att skrivas om till "ssh://example.org/path/to/repo.git" för sändning ("pushas"), men pulls kommer fortfarande att använda den ursprungliga URL:en.

FJÄRR

Namnet på en av följande kan användas istället för en URL som <repo> argument:

en fjärr i Git-konfigurationsfilen: $GIT_DIR/config,
a file in the $GIT_DIR/remotes directory, or
en fil i katalogen $GIT_DIR/branches.

Alla dessa låter dig också utelämna refspec från kommandoraden eftersom de var och en innehåller en refspec som git kommer att använda som standard.

Namngiven fjärr i konfigurationsfilen

Du kan välja att ange namnet på en fjärren som du tidigare konfigurerat med hjälp av git-remote[1], git-config[1] eller till och med genom en manuell redigering av filen $GIT_DIR/config. URL:en för denna fjärrkontroll kommer att användas för att komma åt repot. Refspec:en för denna fjärrkontroll kommer att användas som standard när du inte anger en refspec på kommandoraden. Posten i konfigurationsfilen skulle se ut så här:

	[remote "<name>"]
		url = <URL>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

<pushurl> används endast för sänding ("pusha"). Det är valfritt och standardvärdet är <URL>. Att säda till en fjärr påverkar alla definierade push-adresser eller alla definierade webbadresser om inga sänd-adresser (push) är definierade. Fetch hämtar dock bara från den först definierade webbadressen om flera webbadresser är definierade.

Namngiven fil i `$GIT_DIR/remotes`

Du kan välja att ange namnet på en fil i $GIT_DIR/remotes. URL:en i den här filen kommer att användas för att komma åt repot. Refspec:en i den här filen kommer att användas som standard när du inte anger en refspec på kommandoraden. Den här filen ska ha följande format:

	URL: ett av ovanstående URL-format
	Push: <refspec>
	Pull: <refspec>

Push:-rader används av git push och Pull:-rader används av git pull och git fetch. Flera Push:- och Pull:-rader kan anges för ytterligare grenmappningar.

Namngiven fil i `$GIT_DIR/branches`

Du kan välja att ange namnet på en fil i $GIT_DIR/branches. URL:en i den här filen kommer att användas för att komma åt repot. Filen ska ha följande format:

	<URL>#<huvud>

<URL> krävs; #<huvud> är valfritt.

Beroende på operationen, kommer git att använda en av följande refspecs, om du inte anger någon på kommandoraden. <gren> är namnet på den här filen i $GIT_DIR/branches och <huvud> har som standard master.

git fetch använder:

	refs/heads/<huvud>:refs/heads/<gren>

git push använder:

	HEAD:refs/heads/<huvud>

UPPSTRÖMS-GRENAR

Grenar i Git kan valfritt ha en uppströms fjärrgren. Git använder som standard uppströmsgrenen för fjärroperationer, till exempel:

Det är standardvärdet för git pull eller git fetch utan argument.
It’s the default for git push with no arguments, with some exceptions. For example, you can use the branch.<name>.pushRemote option to push to a different remote than you pull from, and by default with push.default=simple the upstream branch you configure must have the same name.
Olika kommandon, inklusive git checkout och git status, visar hur många incheckningar som har lagts till i din nuvarande grenen och upstream sedan du avgrenade från den, till exempel "Din branch och origin/main har divergerat och har 2 respektive 3 olika incheckningar".

Uppströmmen lagras i .git/config, i fälten "remote" och "merge". Till exempel, om main`s uppström är `origin/main:

[branch "main"]
   remote = origin
   merge = refs/heads/main

Du kan explicit ställa in en uppströmsgren med git push --set-upstream <fjärr> <gren> men Git kommer ofta automatiskt att ställa in uppströmsen åt dig, till exempel:

När du klonar ett repo kommer Git automatiskt att ställa in uppströmmen för standardgrenen.
Om du har konfigurationsalternativet push.autoSetupRemote aktiverat, kommer git push automatiskt att ställa in uppströmsen första gången du pushar en branch.
Att checka ut en fjärrspårningsgren med git checkout <gren> skapar automatiskt en lokal gren med det namnet och ställer in uppströmmen på den fjärranslutna grenen.

Note	Uppströms grenar kallas ibland för "spårningsinformation", som i "ange grenens spårningsinformation".

SAMMANSLAGNINGSSTRATEGIER

Sammanfogningsmekanismen (kommandona git merge och git pull) gör det möjligt att välja bakända-sammanfogningsstrategier med alternativet -s. Vissa strategier kan också ta sina egna alternativ, vilka kan skickas genom att ge -X<alternativ>-argument till git merge och/eller git pull.

ort

Detta är standardstrategin för sammanslagning när man drar in ("pulla") eller sammanfogar en gren. Denna strategi kan bara lösa två huvuden med hjälp av en 3-vägs sammanslagningsalgoritm. När det finns mer än en gemensam förfader som kan användas för 3-vägs sammanslagning skapas ett sammanslaget träd av de gemensamma förfäderna och används som referensträd för 3-vägs sammanslagningen. Detta har rapporterats resultera i färre sammanslagningskonflikter utan att orsaka felsammanslagningar, enligt tester gjorda på faktiska sammanslagningscommits hämtade från Linux 2.6-kärnans utvecklingshistorik. Dessutom kan denna strategi upptäcka och hantera sammanslagningar som involverar namnbyten. Den använder inte upptäckta kopior. Namnet på denna algoritm är en akronym ("Ostensibly Recursive’s Twin") och kommer från det faktum att den skrevs som en ersättning för den tidigare standardalgoritmen, "rekursiv".

I det fall där sökvägen är en undermodul, och undermodul-incheckningen som används på ena sidan av sammanslagnings-sekvensen är en underordnad undermodul-incheckning som används på den andra sidan av merge-sekvensen, försöker Git att snabbspola fram till underordnad. Annars kommer Git att behandla detta fall som en konflikt och föreslå som en lösning en undermodul-incheckningen som är underordnad de konflikterande, om en sådan finns.

ort-strategin kan ha följande alternativ:

ours

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected in the merge result. For a binary file, the entire contents are taken from our side.

Detta bör inte förväxlas med ours sammanslagningsstrategi, som inte ens tittar på vad det andra trädet innehåller alls. Den kasserar allt som det andra trädet gjorde och deklarerar att vår historia innehåller allt som hände i det.

theirs

Detta är motsatsen till ours; observera att det, till skillnad från ours, inte finns någon theirs-sammanslagningsstrategi att förväxla detta sammanslagningsalternativ med.

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

Behandlar rader med den angivna typen av mellanslagsändring som oförändrade för en trevägssammanslagning. Ändringar av mellanslag blandade med andra ändringar på en rad ignoreras inte. Se även git-diff[1] -b, -w, --ignore-space-at-eol och --ignore-cr-at-eol.

Om deras version bara introducerar ändringar av blanksteg på en rad används vår version;
Om vår version introducerar ändringar i blanksteg men deras version inkluderar en väsentlig ändring, används deras version;
Annars fortsätter sammanslagningen på vanligt sätt.

renormalize

Detta kör en virtuell utcheckning och incheckning av alla tre stegen i alla filer som behöver en trevägssammanslagning. Det här alternativet är avsett att användas vid sammanslagning av grenar med olika rena filter eller normaliseringsregler för radslut. Se "Sammanfoga grenar med olika inchecknings-/utcheckningsattribut" i gitattributes[5] för mer information.

no-renormalize

Inaktiverar alternativet renormalize. Detta åsidosätter konfigurationsvariabeln merge.renormalize.

find-renames[=<n>]

Aktivera namnbytesdetektering, och ställ in likhetströskeln om du vill. Detta är standardinställningen. Detta åsidosätter konfigurationsvariabeln merge.renames. Se även git-diff[1] --find-renames.

rename-threshold=<n>

Föråldrad synonym för find-renames=<n>.

no-renames

Stäng av namnbytesdetektering. Detta åsidosätter konfigurationsvariabeln merge.renames. Se även git-diff[1] --no-renames.

histogram

Föråldrad synonym för diff-algoritm=histogram.

patience

Föråldrad synonym för diff-algoritm=tålamod.

diff-algorithm=(histogram|minimal|myers|patience)

Använd en annan diff-algoritm vid sammanfogning, vilket kan bidra till att undvika felsammanfogningar som uppstår på grund av oviktiga matchande rader (som klammerparenteser från olika funktioner). Se även git-diff[1] --diff-algorithm. Observera att ort som standard har diff-algorithm=histogram, medan vanliga diffs för närvarande har konfigurationsinställningen diff.algorithm.

subtree[=<sökväg>]

Det här alternativet är en mer avancerad form av "underträdsstrategi" (subtree), där strategin gissar hur två träd måste flyttas för att matcha varandra vid sammanslagning. Istället prefixeras den angivna sökvägen (eller tas bort från början) för att få formen på de två träden att matcha.

recursive

Detta är nu en synonym för ort. Det var en alternativ implementering fram till v2.49.0, men omdirigerades till att betyda ort i v2.50.0. Den tidigare rekursiva strategin var standardstrategin för att lösa två huvuden från Git v0.99.9k till v2.33.0.

resolve

Detta kan bara lösa två huvuden (dvs. den aktuella grenen och en annan gren du hämtade från) med hjälp av en 3-vägs merge-algoritm. Den försöker noggrant upptäcka korsvisa sammanslagings-tvetydigheter. Den hanterar inte namnbyten.

octopus

Detta löser fall med fler än två huvuden, men vägrar att göra en komplex sammanslagning som kräver manuell lösning. Det är främst avsett att användas för att paketera ämnesgrenhuvuden. Detta är standardsammanslagningsstrategin när man drar in ("pullar") eller sammanfogar mer än en gren.

ours

Detta kan bara lösa två huvuden (dvs. den aktuella grenen och en annan gren du hämtade från) med hjälp av en 3-vägs sammanslagnings-algoritm. Den försöker noggrant upptäcka korsvisa sammanslagnings-tvetydigheter. Den hanterar inte namnbyten.

subtree

Detta är en modifierad ort-strategi. När träd A och B sammanfogas, och B motsvarar ett underträd till A, justeras B först för att matcha trädstrukturen för A, istället för att läsa träden på samma nivå. Denna justering görs också på det gemensamma förfader-trädet.

Med strategier som använder 3-vägssammanslagning (inklusive standardvärdet ort), om en ändring görs på båda grenarna, men senare återställs på en av grenarna, kommer den ändringen att finnas i det sammanslagna resultatet; vissa personer tycker att detta beteende är förvirrande. Det inträffar eftersom endast huvuden och sammanslagningsbasen beaktas när en sammanslagning utförs, inte de enskilda incheckningarna. Sammanslagningsalgoritmen betraktar därför den återställda ändringen som ingen ändring alls och ersätter den ändrade versionen istället.

STANDARDBETEENDE

Ofta använder man git pull utan att ange någon parameter. Traditionellt, har detta motsvarat att säga git pull origin. Men när konfigurationen branch.<namn>.remote finns på grenen <namn>, används det värdet istället för origin.

För att avgöra vilken URL som ska användas för att hämta från, konsulteras värdet för konfigurationen remote.<fjärr>.url och om det inte finns någon sådan variabel används värdet på raden URL: i $GIT_DIR/remotes/<fjärr>.

För att avgöra vilka fjärrgrenar som ska hämtas (och eventuellt lagras i fjärrspårningsgrenarna) när kommandot körs utan några refspec-parametrar på kommandoraden, konsulteras värden för konfigurationsvariabeln remote.<fjärr>.fetch, och om det inte finns några konsulteras $GIT_DIR/remotes/<fjärr> och dess Pull:-rader används. Förutom refspec-formaten som beskrivs i avsnittet OPTIONS kan du ha en globbing-refspec som ser ut så här:

refs/heads/*:refs/remotes/origin/*

En globbande refspec måste ha en icke-tom RHS (dvs. måste lagra det som hämtades i fjärrspårningsgrenar), och dess LHS och RHS måste sluta med /*. Ovanstående anger att alla fjärrgrenar spåras med hjälp av fjärrspårningsgrenar i refs/remotes/origin/-hierarkin under samma namn.

Regeln för att avgöra vilken fjärrgren som ska sammanfogas efter hämtning är lite invecklad för att inte bryta bakåtkompatibiliteten.

Om explicita refspecs angavs på kommandoraden för git pull, slås de alla samman.

När ingen refspec angavs på kommandoraden använder git pull refspec från konfigurationen eller $GIT_DIR/remotes/<fjärr>. I sådana fall gäller följande regler:

Om konfigurationen branch.<namn>.merge för den aktuella branch <namn> finns, är det namnet på branchen på den fjärrplats som slås samman.
Om refspecifikationen är en globbing-specifikation slås ingenting samman.
Annars slås den fjärrgrenen av den första refspecifikationen samman.

EXEMPEL

Uppdatera grenarna för fjärrspårning för det repo du klonade från, och sammanfoga sedan en av dem med din nuvarande gren:
```
$ git pull
$ git pull origin
```
Normalt sett är den sammanslagna grenen HEAD för fjärrarkivet, men valet bestäms av alternativen branch.<name>.remote och branch.<name>.merge; se git-config[1] för detaljer.
Sammanfoga den fjärrstyrda grenen next med den aktuella grenen:
```
$ git pull origin next
```
Detta lämnar en kopia av next tillfälligt i FETCH_HEAD och uppdaterar fjärrspårningsgrenen origin/next. Detsamma kan göras genom att anropa fetch och merge:
```
$ git fetch origin
$ git merge origin/next
```

If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with git reset.

SÄKERHET

Protokollen för hämtning (fetch) och sänd ("pusha") är inte utformade för att förhindra att en sida stjäl data från det andra repot som inte var avsedda att delas. Om du har privata data som du behöver skydda från en skadlig motpart är det bästa alternativet att lagra dem i ett annat repo. Detta gäller både klienter och servrar. Namnrymder på en server är särskilt inte effektiva för läsåtkomstkontroll; du bör bara bevilja läsåtkomst till ett namnrymd till klienter som du skulle anförtro läsåtkomst till hela repot.

De kända attackvektorerna är följande:

Offret skickar "har"-rader som annonserar ID:n för objekt som det har som inte uttryckligen är avsedda att delas men som kan användas för att optimera överföringen om motparten också har dem. Angriparen väljer ett objekt-ID X att stjäla och skickar en referens till X, men är inte skyldig att skicka innehållet i X eftersom offret redan har det. Nu tror offret att angriparen har X, och skickar tillbaka innehållet i X till angriparen senare. (Denna attack är enklast för en klient att utföra på en server, genom att skapa en referens till X i namnrymden som klienten har tillgång till och sedan hämta den. Det mest troliga sättet för en server att utföra den på en klient är att "sammanfoga" X till en offentlig gren och hoppas att användaren gör ytterligare arbete på denna gren och skickar tillbaka den till servern utan att märka sammanfogningen.)
Precis som i punkt 1 väljer angriparen ett objekt-ID X att stjäla. Offret skickar ett objekt Y som angriparen redan har, och angriparen påstår falskeligen att ha X och inte Y, så offret skickar Y som ett delta mot X. Deltat avslöjar regioner av X som liknar Y för angriparen.

BUGGAR

Att använda --recurse-submodules kan bara hämta nya incheckningar i redan utcheckade undermoduler just nu. När t.ex. upstream lägger till en ny undermodul i de just hämtade incheckningar i superprojektet kan inte själva undermodulen hämtas, vilket gör det omöjligt att checka ut den undermodulen senare utan att behöva göra en hämtning (fetch) igen. Detta förväntas bli åtgärdat i en framtida Git-version.

SE ÄVEN

git-fetch[1], git-merge[1], git-config[1]

En del av git[1]-sviten

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands