Git

git-fetch last updated in 2.53.0

NAMN

git-fetch - Ladda ner objekt och referenser från ett annat förvar

SYNOPSIS

git fetch [<opflaggortions>] [<kodförråd> [<refspec>…]]
git fetch [<flaggor>] <grupp>
git fetch --multiple [<flaggor>] [(<kodförråd>|<grupp>)…]
git fetch --all [<flaggor>]

BESKRIVNING

Hämta grenar och/eller taggar (gemensamt kallade "referenser") från ett eller flera andra kodförråd, tillsammans med de objekt som krävs för att slutföra deras historik. Fjärrspårningsgrenar uppdateras (se beskrivningen av <refspec> nedan för sätt att kontrollera detta beteende).

Som standard, hämtas även alla taggar som pekar in i de historiker som hämtas; effekten är att hämta taggar som pekar på grenar som du är intresserad av. Detta standardbeteende kan ändras genom att använda alternativen --tags eller --no-tags eller genom att konfigurera remote.<namn>.tagOpt. Genom att använda en referensspecifikation som hämtar taggar explicit kan du också hämta taggar som inte pekar in på grenar som du är intresserad av.

git fetch kan hämta från antingen ett enda namngivet kodförråd eller URL, eller från flera kodförråd samtidigt om <grupp> anges och det finns en remotes.<grupp>-post i konfigurationsfilen. (Se git-config[1]).

När ingen fjärr anges används som standard fjärren origin, såvida det inte finns en uppströmsgren konfigurerad för den aktuella grenen.

Namnen på referenser som hämtas, tillsammans med objektnamnen de pekar på, skrivs till .git/FETCH_HEAD. Denna information kan användas av skript eller andra git-kommandon, till exempel git-pull[1].

ALTERNATIV

--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-kodförråd (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>: spetsenspetsenLiknar --depth, förutom att den anger antalet incheckningar från den aktuella ytliga gränsen istället för från topen av varje fjärrgrenhistorik.
--shallow-since=<datum>: Fördjupa eller förkorta historiken för ett ytligt kodförråd för att inkludera alla nåbara incheckningar efter <datum>.
--shallow-exclude=<ref>: Fördjupa eller förkorta historiken för ett ytligt kodförråd 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 kodförråd till ett komplett, och ta bort alla begränsningar som ytliga repon medför.

Om källkodförrådet är ytligt, hämta så mycket som möjligt så att det aktuella kodförrådet har samma historik som källkodförrådet.
--update-shallow: Som standard vid hämtning från ett ytligt kodförråd, 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 toppar. 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.
--write-fetch-head
--no-write-fetch-head: Skriv listan över hämtade fjärrreferenser i filen FETCH_HEAD direkt under $GIT_DIR. Detta är standardinställningen. Om --no-write-fetch-head skickas från kommandoraden får Git besked om att inte skriva filen. Med alternativet --dry-run skrivs filen aldrig.
-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>_s-delen nedan. Det här alternativet åsidosätter den kontrollen.
-k
--keep: Behåll hämtade paket.
--multiple: Tillåt att flera <kodförråd>- och <grupp>-argument anges. Inga <refspec>s-argument får anges.
--auto-maintenance
--no-auto-maintenance
--auto-gc
--no-auto-gc: Kör git maintenance run --auto i slutet för att utföra automatiskt underhåll av kodförrådet om det behövs. Detta är aktiverat som standard.
--write-commit-graph
--no-write-commit-graph: Skriv en inchecknings-graf efter hämtning. Detta åsidosätter konfigurationsinställningen fetch.writeCommitGraph.
--prefetch: Ändra den konfigurerade referensspecifikationen 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 referensspecifikation (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 referensspecifikation.

Se avsnittet BESÄRNING nedan för mer information.
-P
--prune-tags: Innan du hämtar, ta bort alla lokala taggar som inte längre finns på fjärren om --prune är aktiverat. Det här alternativet bör användas mer försiktigt, till skillnad från --prune tar det bort alla lokala referenser (lokala taggar) som har skapats. Det här alternativet är en förkortning för att tillhandahålla den explicita taggens referensspecifikation tillsammans med --prune, se diskussionen om det i dess dokumentation.

Se avsnittet BESÄRNING nedan för mer information.
-n
--no-tags: Som standard, hämtas och lagras taggar som pekar på objekt som laddas ner från fjärrkodförrådet 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].
--refetch: Istället för att förhandla med servern för att undvika att överföra incheckningar och tillhörande objekt som redan finns lokalt, hämtar det här alternativet alla objekt som en ny klon skulle göra. Använd detta för att återanvända ett partiellt klonfilter från konfigurationen eller med hjälp av --filter= när filterdefinitionen har ändrats. Automatiskt underhåll efter hämtning (fetch) utför konsolidering av objektdatabaspaket för att ta bort eventuella dubbletter av objekt.
--refmap=<refspec>: När du hämtar referenser som listas på kommandoraden, använd den angivna referensspecifikationen (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ärrkodförrådet. Om du anger en tomt <refspec> till alternativet --refmap ignorerar Git de konfigurerade referensspecifikationer och förlitar sig helt på de referensspecifikationer som anges som kommandoradsargument. Se avsnittet om "Konfigurerade fjärrspårningsgrenar" för mer information.
-t
--tags: Hämta alla taggar från fjärren (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 referensspecifikation; se --prune).
--recurse-submodules[=(yes|on-demand|no)]: Kontrollera om och under vilka villkor nya incheckning för undermoduler också ska hämtas. Vid rekursiv genom undermoduler försöker git fetch alltid hämta "ändrade" undermoduler, det vill säga en undermodul som har incheckningar som refereras till av en nyligen hämtad superprojektsincheckning men saknas i den lokala undermodul-klonen. En ändrad submodul kan hämtas så länge den finns lokalt, t.ex. i $GIT_DIR/modules/ (se gitsubmodules[7]); om uppströmen lägger till en ny submodul kan den undermodulen inte hämtas förrän den klonas, t.ex. av git submodule update.

När den är inställd på on-demand hämtas endast ändrade undermoduler. När den är inställd på yes hämtas alla ifyllda undermoduler och undermoduler som både är ofyllda och ändrade hämtas. När den är inställd på no hämtas aldrig undermoduler.

Om det inte är angivet använder detta värdet för fetch.recurseSubmodules om det är satt (se git-config[1]), och standardvärdet är on-demand om det inte är satt. När det här alternativet används utan något värde används standardvärdet yes.
-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.
--no-recurse-submodules: Inaktivera rekursiv hämtning av undermoduler (detta har samma effekt som att använda alternativet --recurse-submodules=no).
--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].
--submodule-prefix=<sökväg>: Lägg till <sökväg> framför sökvägar som skrivs ut i informativa meddelanden som "Hämtar undermodule foo". Detta alternativ används internt vid rekursion över undermodul.
--recurse-submodules-default=(yes|on-demand): Det här alternativet används internt för att tillfälligt tillhandahålla ett icke-negativt standardvärde för alternativet --recurse-submodules. Alla andra metoder för att konfigurera hämtingar (fetchs) undermoduls-rekursion (som inställningar i gitmodules[5] och git-config[1]) åsidosätter det här alternativet, liksom att ange --[no-]recurse-submodules direkt.
-u
--update-head-ok: Som standard vägrar git fetch att uppdatera huvud-filen som motsvarar den aktuella grenen. Denna flagga inaktiverar kontrollen. Detta är enbart för internt bruk för git pull att kommunicera med git fetch, och om du inte implementerar ditt eget Porslin ska du inte använda det.
--upload-pack <upload-pack>: När det anges, och kodförrådet 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.
-q
--quiet: Skicka --quiet till git-fetch-pack och tysta alla andra internt använda git-kommandon. Förloppet rapporteras inte till standardfelströmmen.
-v
--verbose: Var utförlig.
--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.

<repository>: "Fjärr"-kodförrådet som är källan för en fetch- eller pull-operation. Parametern kan antingen vara en URL (se avsnittet GIT URLS nedan) eller namnet på en fjärr (se avsnittet FJÄRRAR nedan).
<grupp>: Ett namn som refererar till en lista över arkiv som värdet för remotes.<grupp> i konfigurationsfilen. (Se git-config[1]).

<refspec>

Anger vilka referenser som ska uppdateras och vilka lokala referenser som ska uppdateras. När inga <refspec>ar visas på kommandoraden läses referenserna som ska uppdateras från variablerna remote.<repository>.fetch i stället (se KONFIGURERADE FJÄRRSPÅRNINGSGRENAR nedan)..

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 referensspecifikation 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 referensspecifikation har prefixet ^ kommer den att tolkas som en negativ referensspecifikation. I stället för att ange vilka referenser som ska uppdateras eller vilka lokala referenser som ska uppdateras, kommer en sådan referensspecifikation i stället att ange referenser som ska exkluderas. En referens kommer att anses matcha om den matchar minst en positiv referensspecifikation och inte matchar någon negativ referensspecifikation. Negativa referensspecifikationer kan vara användbara för att begränsa omfattningen av en mönsterrefspec så att den inte inkluderar specifika referenser. Negativa referensspecifikationer kan själva vara mönsterrefspecar. 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 uppdateras till, typen av objekt som uppdateras och om uppdateringen anses vara en snabbspolning. I allmänhet gäller samma regler för uppdatering som när man skickar; se avsnittet <refspec>... i git-push[1] för vilka regler det gäller. 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 skickar med git-push[1], skulle alla uppdateringar till refs/tags/* accepteras utan + i referensspecifikationen (eller --force). Vid uppdatering betraktade vi promiskuöst alla tagguppdateringar från en fjärr som tvångsuppdateringar. Sedan Git version 2.20 fungerar uppdatering för att uppdatera refs/tags/* på samma sätt som när man skickar. Dvs. alla uppdateringar kommer att avvisas utan + i referensspecifikationen (eller --force).

Till skillnad från när man skickar med git-push[1], kommer alla uppdateringar utanför refs/{tags,heads}/* att accepteras utan + i referensspecifikationen (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 skickar 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 när man skickar 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 referensspecifikation (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-incheckningsobjekt.

Note

När den fjärrgren du vill uppdatera är känd för att regelbundet spolas tillbaka och ombaseras, förväntas det att dess nya topp inte kommer att vara en efterföljare till dess tidigare topp (som lagrats i din fjärrspårade gren förra gången du uppdaterade). Du vill använda +-tecknet för att indikera att uppdateringar som inte är snabbspolningar 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 kodförråd med detta beteende; den uppdaterande användaren måste helt enkelt veta att detta är det förväntade användningsmönstret för en gren.

--stdin: Läs referensspecifikationer, en per rad, från stdin utöver de som anges som argument. Formatet "tag <namn>" stöds inte.

GIT URLS

I allmänhet innehåller URL:er information om transportprotokollet, adressen till fjärrservern och sökvägen till kodförråd. 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-kodförråd>
git://<värd>[:<port>]/<sökväg-till-git-kodförråd>
http[s]://<värd>[:<port>]/<sökväg-till-git-kodförråd>
ftp[s]://<värd>[:<port>]/<sökväg-till-git-kodförråd>

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

[<användare>@]<värd>:/<sökväg-till-git-kodförråd>

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>]/~<användare>/<sökväg-till-git-kodförråd>
git://[<användare>@]<värd>[:<port>]/<sökväg-till-git-kodförråd>
[<användare>@]<värd>[:<port>]/<sökväg-till-git-kodförråd>

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

/sokvag/till/kodförråd.git/
file:///sokvag/till/kodförråd.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älpprogram remote-<transport>, om en sådan finns. För att explicit begära en fjärr-hjälpprogram 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:kodförråd.git" eller "host.xz:/sokvag/till/kodförråd.git" kommer att skrivas om i alla sammanhang som antar att URL:en är "git://git.host.xz/kodförråd.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 <kodförråd> argument:

en fjärr i Git-konfigurationsfilen: $GIT_DIR/config,
en fil i katalogen $GIT_DIR/remotes, eller
en fil i katalogen $GIT_DIR/branches.

Alla dessa låter dig också utelämna referensspecifikationen från kommandoraden eftersom de var och en innehåller en referensspecifikation 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ärr kommer att användas för att komma åt kodförrådet. Referensspecifikationen för denna fjärr kommer att användas som standard när du inte anger en referensspecifikation 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 kodförrådet. Referensspecifikationen i den här filen kommer att användas som standard när du inte anger en referensspecifikation 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 kodförrådet. 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 referensspecifikationer, 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.
Det är standardinställningen för git push utan argument, med vissa undantag. Du kan till exempel använda alternativet branch.<name>.pushRemote för att pusha till en annan fjärr än den du hämtar från, och som standard med push.default=simple måste den uppströmsgren du konfigurerar ha samma namn.
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 uppstrom ä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 kodförråd 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".

KONFIGURERADE FJÄRSPÅRNINGSGRENAR

Du interagerar ofta med samma fjärrkodförråd genom att regelbundet och upprepade gånger hämta data från det. För att hålla koll på förloppet för ett sådant fjärrkodförråd låter git fetch dig konfigurera konfigurationsvariabler remote.<kodförråd>.fetch.

Vanligtvis kan en sådan variabel se ut så här:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*

Denna konfiguration används på två sätt:

När git fetch körs utan att ange vilka grenar och/eller taggar som ska hämtas på kommandoraden, t.ex. git fetch origin eller git fetch, används remote.<kodförråd>.fetch-värden som referensspecifikationer– de anger vilka referenser som ska hämtas och vilka lokala referenser som ska uppdateras. Exemplet ovan hämtar alla grenar som finns i origin (dvs. alla referenser som matchar vänster sida av värdet refs/heads/*) och uppdaterar motsvarande fjärrspårningsgrenar i refs/remotes/origin/*-hierarkin.
När git fetch körs med explicita grenar och/eller taggar för att hämta på kommandoraden, t.ex. git fetch origin master, bestämmer <refspec>er som anges på kommandoraden vad som ska hämtas (t.ex. master i exemplet, vilket är en förkortning för master:, vilket i sin tur betyder "hämta master-grenen men jag säger inte explicit vilken fjärrspårningsgren som ska uppdateras med den från kommandoraden"), och exempelkommandot hämtar endast master-grenen. Värdena för remote.<kodförråd>.fetch bestämmer vilken fjärrspårningsgren, om någon, som uppdateras. När de används på detta sätt har remote.<kodförråd>.fetch-värdena ingen effekt på att bestämma vad som hämtas (dvs. värdena används inte som referensspecifikationer när kommandoraden listar referensspecifikationer); De används bara för att bestämma var de hämtade referenserna lagras genom att fungera som en mappning.

Den senare användningen av remote.<kodförråd>.fetch-värdena kan åsidosättas genom att ange parametern(erna) --refmap=<refspec> på kommandoraden.

BESKÄRNING

Git har som standard att behålla data om den inte uttryckligen raderas; detta omfattar även att behålla lokala referenser till grenar på fjärrdatorer som själva har tagit bort dessa grenar.

Om de får ansamlas, kan dessa inaktuella referenser försämra prestandan på stora och upptagna kodförråd med mycket gren-omsättning, och t.ex. göra utdata från kommandon som git branch -a --contains <incheckning> onödigt utförliga, samt påverka allt annat som fungerar med den kompletta uppsättningen kända referenser.

Dessa fjärrspårningsreferenser kan raderas en gång för sig med något av följande:

# Medan hämtning
$ git fetch --prune <namn>

# Beskär bara, hämta inte
$ git remote prune <namn>

För att rensa referenser som en del av ditt vanliga arbetsflöde utan att behöva komma ihåg att köra det, sätt fetch.prune globalt, eller remote.<namn>.prune per-remote i konfigurationen. Se git-config[1].

Det är här det blir knepigt och mer specifikt. Beskärningsfunktionen bryr sig egentligen inte om grenar, istället beskär den lokala ←→ fjärrreferenser som en funktion av fjärrens referensspecifikation (se <refspec> och KONFIGURERADE FJÄRSPÅRNINGSFILIER ovan).

Om därför referensspecifikationen för fjärren inkluderar t.ex. refs/tags/*:refs/tags/*, eller om du manuellt kör t.ex. git fetch --prune <namn> "refs/tags/*:refs/tags/*", kommer det inte att vara inaktuella grenar för fjärrspårning som tas bort, utan alla lokala taggar som inte finns på fjärren.

Det här kanske inte är vad du förväntar dig, d.v.s. du vill rensa fjärren <namn>, men också explicit hämta taggar från den, så när du hämtar från den raderar du alla dina lokala taggar, varav de flesta kanske inte kom från fjärren <namn> från första början.

Så var försiktig när du använder detta med en referensspecifikation som refs/tags/*:refs/tags/*, eller någon annan referensspecifikation som kan mappa referenser från flera fjärrenheter till samma lokala namnrymd.

Eftersom det är vanligt att hålla sig uppdaterad med både grenar och taggar på fjärren kan alternativet --prune-tags anges tillsammans med --prune för att rensa bort lokala taggar som inte finns på fjärren och tvångsuppdatera de taggar som skiljer sig åt. Taggrensning kan också aktiveras med fetch.pruneTags eller remote.<namn>.pruneTags i konfigurationen. Se git-config[1].

Alternativet --prune-tags motsvarar att refs/tags/*:refs/tags/* deklareras i fjärrens referensspecifikationer. Detta kan leda till en del till synes konstiga interaktioner:

# Båda dessa hämtningstaggar
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --no-tags --prune-tags origin

Anledningen till att det inte ger felar-ut när det anges utan --prune eller dess konfigurationsversioner är för flexibiliteten hos de konfigurerade versionerna, och för att bibehålla en 1=1-mappning mellan vad kommandoradsflaggorna gör och vad konfigurationsversionerna gör.

Det är rimligt att t.ex. konfigurera fetch.pruneTags=true i ~/.gitconfig så att taggar rensas varje gång git fetch --prune körs, utan att göra varje anrop av git fetch utan --prune till ett fel.

Att rensa taggar med --prune-tags fungerar också när man hämtar en URL istället för en namngiven fjärr. Dessa kommer att rensa alla taggar som inte hittas på ursprungsadressen:

$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
$ git fetch <url-of-origin> --prune --prune-tags
$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'

UTMATNING

Utdata från "git fetch" beror på vilken transportmetod som används; det här avsnittet beskriver utdata vid hämtning över Git-protokollet (antingen lokalt eller via ssh) och Smart HTTP-protokollet.

Statusen för hämtningen visas i tabellform, där varje rad representerar statusen för en enskild referens. Varje rad har formen:

 <flagga> <sammanfattning> <från> -> <till> [<orsak>]

När --porcelain används, är utdataformatet avsett att vara maskinläsbart. Till skillnad från de mänskligt läsbara utdataformaten skrivs det således ut med standardut istället för standardfel. Varje rad har formatet:

<flagga> <gammalt-objekt-id> <nytt-objekt-id> <lokal-referens>

Status för uppdaterade referenser visas endast om alternativet --verbose används.

I kompakt utdataläge, specificerat med konfigurationsvariabeln fetch.output, om antingen hela <från> eller <till> hittas i den andra strängen, kommer den att ersättas med * i den andra strängen. Till exempel blir master -> origin/master master -> origin/*.

flagga

Ett enda tecken som anger referensens status:

(mellanslag): för en lyckad hämtad snabbspolning framåt;
+: för en lyckad påtvingad uppdatering;
-: för en framgångsrikt beskuren ref;
t: för en lyckad tagguppdatering;
*: för en framgångsrikt hämtad ny ref;
!: för en referens som avvisades eller inte kunde uppdateras; och
=: för en domare som var aktuell och inte behövde hämtas.

summary

För en lyckat hämtad referens visar sammanfattningen de gamla och nya värdena för referensen i en form som är lämplig att använda som ett argument till git log (detta är <gammal>..<ny> i de flesta fall, och <gammal>...<ny> för tvingade uppdateringar som inte snabbspolas framåt).

från

Namnet på den fjärrreferens som hämtas från, minus dess prefix refs/<typ>/. Vid borttagning är namnet på fjärrreferensen "(ingen)".

till

Namnet på den lokala referensen som uppdateras, minus dess prefix refs/<typ>/.

skäl

En människoläsbar förklaring. Om referenserna har hämtats, behövs ingen förklaring. För en misslyckad referens, beskrivs orsaken till misslyckandet.

EXEMPEL

Uppdatera de fjärrspårade grenarna:
```
$ git fetch origin
```
Kommandot ovan kopierar alla grenar från namnrymden refs/heads/ och lagrar dem i den lokala namnrymden refs/remotes/origin/, såvida inte alternativet remote.<kodförråd>.fetch används för att ange en referensspecifikation som inte är standard.
Använda referensspecifikationer explicit:
```
$ git fetch origin +seen:seen maint:tmp
```
Detta uppdaterar (eller skapar, vid behov) grenarna sedd och tmp i det lokala arkivet genom att hämta från grenarna (respektive) sedd och maint från fjärrarkivet.

Grenen sedd kommer att uppdateras även om den inte snabbspolar framåt, eftersom den har ett plustecken som prefix; tmp kommer inte att göra det.
Titta på en fjärrens gren, utan att konfigurera fjärren i ditt lokala arkiv:
```
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD
```
Det första kommandot hämtar grenen maint från arkivet på git://git.kernel.org/pub/scm/git/git.git och det andra kommandot använder FETCH_HEAD för att undersöka grenen med git-log[1]. De hämtade objekten kommer så småningom att tas bort av gits inbyggda housekeeping (se git-gc[1]).

SÄKERHET

Protokollen för hämtning (fetch) och sänd ("skicka") är inte utformade för att förhindra att en sida stjäl data från det andra kodförrådet 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 kodförråd. 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 kodförrådet.

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 sammanslagningen.)
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.

KONFIGURATION

Allt under den här raden i det här avsnittet är selektivt inkluderat från dokumentationen git-config[1]. Innehållet är detsamma som det som finns där:

fetch.recurseSubmodules: Det här alternativet styr om git fetch (och den underliggande hämtningen i git pull) rekursivt ska hämta till ifyllda undermoduler. Det här alternativet kan ställas in antingen på ett booleskt värde eller på on-demand. Att ställa in det på ett booleskt värde ändrar beteendet för fetch and pull så att de villkorslöst rekurserar till undermoduler när de är satta till true (sant) eller till att inte rekursera alls när de är satta till false (falskt). När de är satta till on-demand kommer fetch and pull bara att rekursera till en ifylld undermodul när dess superprojekt hämtar en commit som uppdaterar undermodulens referens. Standardvärdet är on-demand, eller till värdet för submodule.recurse om det är satt.
fetch.fsckObjects: Om den är satt till sant kommer git-fetch-pack att kontrollera alla hämtade objekt. Se transfer.fsckObjects för vad som är markerat. Standardvärdet är false. Om det inte är satt används värdet för transfer.fsckObjects istället.
fetch.fsck.<medd-id>: Fungerar som fsck.<medd-id>, men används av git-fetch-pack[1] istället för git-fsck[1]. Se dokumentationen för fsck.<medd-id> för mer information.
fetch.fsck.skipList: Fungerar som fsck.skipList, men används av git-fetch-pack[1] istället för git-fsck[1]. Se dokumentationen för fsck.skipList för mer information.
fetch.unpackLimit: Om antalet objekt som hämtas via Git-överföringen understiger denna gräns, kommer objekten att packas upp till lösa objektfiler. Om antalet mottagna objekt däremot är lika med eller överstiger denna gräns, kommer det mottagna paketet att lagras som ett paket, efter att eventuella saknade deltabaser har lagts till. Att lagra paketet från en push-operation kan göra att push-operationen slutförs snabbare, särskilt på långsamma filsystem. Om det inte är angivet används värdet transfer.unpackLimit istället.
fetch.prune: Om sant, kommer fetch automatiskt att bete sig som om --prune-alternativet angavs på kommandoraden. Se även remote.<namn>.prune och BESKÄRNING-sektionen i git-fetch[1].
fetch.pruneTags: Om sant, kommer fetch automatiskt att bete sig som om refs/tags/*:refs/tags/* refspec angavs vid beskärning, om den inte redan är angiven. Detta gör det möjligt att ställa in både detta alternativ och fetch.prune för att bibehålla en 1=1-mappning till uppströmsreferenser. Se även remote.<namn>.pruneTags och BESKÄRNING-sektionen i git-fetch[1].
fetch.all: Om sant, kommer fetch att försöka uppdatera alla tillgängliga fjärrar. Detta beteende kan åsidosättas genom att skicka --no-all eller genom att explicit ange en eller flera fjärrar att hämta från. Standardvärdet är false.
fetch.output: Styr hur referensuppdateringsstatus skrivs ut. Giltiga värden är full och compact. Standardvärdet är full. Se avsnittet UTMATNING i git-fetch[1] för mer information.
fetch.negotiationAlgorithm: Styr hur information om incheckningar i det lokala förvaret skickas vid förhandling av innehållet i packfilen som ska skickas av servern. Ställ in på consecutive för att använda en algoritm som går över på varandra följande incheckningar och kontrollerar var och en. Ställ in på skipping för att använda en algoritm som hoppar över incheckningar i ett försök att konvergera snabbare, men kan resultera i en packfil som är större än nödvändigt; eller sätt på noop för att inte skicka någon information alls, vilket nästan säkert kommer att resultera i en packfil som är större än nödvändigt, men som hoppar över förhandlingssteget. Ställ in på default för att åsidosätta inställningar som gjorts tidigare och använda standardbeteendet. Standardvärdet är normalt consecutive, men om feature.experimental är true är standardvärdet skipping. Okända värden kommer att orsaka att git fetch ger fel.

Se även alternativen --negotiate-only och --negotiation-tip för git-fetch[1].
fetch.showForcedUpdates: Sätt till false för att aktivera --no-show-forced-updates i kommandona git-fetch[1] och git-pull[1]. Standardvärdet är true.
fetch.parallel: Anger det maximala antalet hämtningsoperationer som ska köras parallellt samtidigt (undermoduler eller fjärrar när --multiple-alternativet i git-fetch[1] är aktivt).

Ett värde på 0 ger en rimlig standardinställning. Om den inte är inställd är standardvärdet 1.

For submodules, this setting can be overridden using the submodule.fetchJobs config setting.
fetch.writeCommitGraph: Sätt till true för att skriva en inchecknings-graph efter varje git fetch-kommando som laddar ner en pack-fil från en fjärr. Med alternativet --split skapar de flesta körningar en mycket liten inchecknings-graph-fil ovanpå den/de befintliga inchecknings-graph-filen/filerna. Ibland slås dessa filer samman och skrivningen kan ta längre tid. Att ha en uppdaterad inchecknings-graph-fil hjälper till att utföra många Git-kommandon, inklusive git merge-base, git push -f och git log --graph. Standardvärdet är false.
fetch.bundleURI: Det här värdet lagrar en URI för att ladda ner Git-objektdata från en bunt-URI innan en stegvis hämtning utförs från den ursprungliga Git-servern. Detta liknar hur alternativet --bundle-uri beter sig i git-clone[1]. git clone --bundle-uri kommer att ställa in värdet fetch.bundleURI om den angivna bunt-URI:n innehåller en bunt-lista som är organiserad för stegvisa hämtningar.

Om du ändrar det här värdet och ditt förvar har ett fetch.bundleCreationToken-värde, ta bort det fetch.bundleCreationToken-värdet innan du hämtar från den nya bunt-URI:n.
fetch.bundleCreationToken: När fetch.bundleURI används för att hämta stegvis från en bunt-lista som använder heuristiken "creationToken", lagrar detta konfigurationsvärde det maximala creationToken-värdet för de nedladdade buntarna. Detta värde används för att förhindra nedladdning av buntar i framtiden om den annonserade creationToken inte är strikt större än detta värde.

Värdena för skapandetoken väljs av leverantören som hanterar den specifika bunt-URI:n. Om du ändrar URI:n vid fetch.bundleURI, se till att ta bort värdet för fetch.bundleCreationToken innan hämtningen.

BUGGAR

Att använda --recurse-submodules kan bara hämta nya incheckningar i undermoduler som finns lokalt, t.ex. i $GIT_DIR/modules/. Om uppströmsmodulen lägger till en ny undermodul kan den undermodulen inte hämtas förrän den klonas, t.ex. av git submodule update. Detta förväntas bli åtgärdat i en framtida Git-version.

SE ÄVEN

git-pull[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