Svenska ▾ Topics ▾ Latest version ▾ git-fetch last updated in 2.53.0

NAMN

git-fetch - Download objects and refs from another repository

SYNOPSIS

git fetch [<opflaggortions>] [<förvar> [<refspec>…​]]
git fetch [<flaggor>] <grupp>
git fetch --multiple [<flaggor>] [(<förvar>|<grupp>)…​]
git fetch --all [<flaggor>]

BESKRIVNING

Hämta grenar och/eller taggar (gemensamt kallade "referenser") från ett eller flera andra förvar, 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 refspec 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 förvar eller URL, eller från flera förvar 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-förvar (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 förvar för att inkludera alla nåbara incheckningar efter <datum>.

--shallow-exclude=<ref>

Fördjupa eller förkorta historiken för ett ytligt förvar 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 förvar till ett komplett, och ta bort alla begränsningar som ytliga repon medför.

Om käll-förvaret är ytligt, hämta så mycket som möjligt så att det aktuella förvaret har samma historik som käll-förvaret.

--update-shallow

Som standard vid hämtning från ett ytligt förvar, 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>-delen nedan. Det här alternativet åsidosätter den kontrollen.

-k
--keep

Behåll hämtade paket.

--multiple

Tillåt att flera <förvar>- och <grupp>-argument anges. Inga <refspec>-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 förvaret 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 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.

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 tagg refspec 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ärrförvaret 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 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ärrförvaret. 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).

--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 Porcelain ska du inte använda det.

--upload-pack <upload-pack>

När det anges, och förvaret 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.

<förvar>

The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).

<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 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.<förvar>.fetch istä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 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 top inte kommer att vara en underordnad av dess tidigare top (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 förvar 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.
--stdin

Läs refspecs, 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 förvar. 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-förvar>

  • git://<värd>[:<port>]/<sökväg-till-git-förvar>

  • http[s]://<värd>[:<port>]/<sökväg-till-git-förvar>

  • ftp[s]://<värd>[:<port>]/<sökväg-till-git-förvar>

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

  • [<användare>@]<värd>:/<sökväg-till-git-förvar>

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-förvar>

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

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

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

  • /sokvag/till/förvar.git/

  • file:///sokvag/till/förvar.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:förvar.git" eller "host.xz:/sokvag/till/förvar.git" kommer att skrivas om i alla sammanhang som antar att URL:en är "git://git.host.xz/förvar.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 <förvar> 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 förvaret. 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 förvaret. 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 förvaret. 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 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 förvar 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ärrförvar 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ärrförvar låter git fetch dig konfigurera konfigurationsvariabler remote.<förvar>.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.<förvar>.fetch-värden som refspecs – 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>s 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.<förvar>.fetch bestämmer vilken fjärrspårningsgren, om någon, som uppdateras. När de används på detta sätt har remote.<förvar>.fetch-värdena ingen effekt på att bestämma vad som hämtas (dvs. värdena används inte som refspecs när kommandoraden listar refspecs); 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.<förvar>.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 förvar 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ärrkontrollens refspec (se <refspec> och KONFIGURERADE FJÄRSPÅRNINGSFILIER ovan).

Om därför refspec:en för fjärrkontrollen 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ärrkontrollen <namn> från första början.

Så var försiktig när du använder detta med en refspec som refs/tags/*:refs/tags/*, eller någon annan refspec 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 refspecs. 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>]

When using --porcelain, the output format is intended to be machine-parseable. In contrast to the human-readable output formats it thus prints to standard output instead of standard error. Each line is of the form:

<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.<förvar>.fetch används för att ange en refspec som inte är standard.

  • Använda refspecs 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 ("pusha") är inte utformade för att förhindra att en sida stjäl data från det andra förvaret 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 förvar. 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 förvaret.

De kända attackvektorerna är följande:

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

  2. 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:

Warning

Missing sv/config/fetch.adoc

See original version for this content.

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]

GIT

En del av git[1]-sviten