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

NAMN

git-push - Uppdatera fjärr-referenser och tillhörande objekt

SYNOPSIS

git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
	 [--repo=<förvar>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
	 [-u | --set-upstream] [-o <string> | --push-option=<sträng>]
	 [--[no-]signed | --signed=(true|false|if-asked)]
	 [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
	 [--no-verify] [<förvar> [<refspec>…​]]

BESKRIVNING

Uppdaterar en eller flera grenar, taggar eller andra referenser i ett fjärrförvar från ditt lokala förvar och skickar all nödvändig data som inte redan finns på fjärren.

Det enklaste sättet att pusha är git push <fjärr> <gren>. git push origin main kommer att sända den lokala main-grenen till main-grenen på fjärren med namnet origin.

Argumentet <förvar> är som standard uppströms för den aktuella grenen, eller origin om det inte finns någon konfigurerad uppströms.

För att bestämma vilka grenar, taggar eller andra referenser som ska sändas ("pushas") använder Git (i prioritetsordning):

  1. Argumentet/argumenten <refspec> (till exempel main i git push origin main) eller alternativen --all, --mirror eller --tags

  2. Konfigurationen remote.<namn>.push för förvaret som sänds till

  3. Konfigurationen push.default. Standardinställningen är push.default=simple, vilket skickar till en gren med samma namn som den aktuella grenen. Se avsnittet KONFIGURATION nedan för mer information om push.default.

git push kan misslyckas om du inte har ställt in en uppström för den aktuella grenen, beroende på vad push.default är inställt på. Se avsnittet UPPSTRÖMS GRENAR nedan för mer information om hur man ställer in och använder uppström.

Du kan få intressanta saker att hända med ett förvar varje gång du skickar in det, genom att sätta upp krokar ("hooks") där. Se dokumentationen för git-receive-pack[1].

ALTERNATIV

<förvar>

Det "fjärr" förvar som är destinationen för en sänd-operation. Denna parameter kan antingen vara en URL (se avsnittet GIT URLS nedan) eller namnet på en fjärren (se avsnittet FJÄRRAR nedan).

<refspec>...

Ange vilken destinationsreferens som ska uppdateras med vilket källobjekt.

Formatet för en refspec är [+]<src>[:<mål>], till exempel main, main:other eller HEAD^:refs/heads/main.

<src> är ofta namnet på den lokala grenen som ska skickas, men det kan vara vilket godtyckligt "SHA-1-uttryck" som helst (se gitrevisions[7]).

<mål> avgör vilken referens som ska uppdateras på fjärrsidan. Det måste vara namnet på en gren, tagg eller annan referens, inte ett godtyckligt uttryck.

+ är valfritt och gör samma sak som --force.

Du kan skriva en refspec med hjälp av den helt expanderade formen (till exempel refs/heads/main:refs/heads/main) som anger exakt källa och destination, eller med en kortare form (till exempel main eller main:other). Här är reglerna för hur refspecs expanderas, såväl som olika andra speciella refspec-former:

  • <src> utan :<mål> innebär att uppdatera samma referens som <src>, såvida inte konfigurationen remote.<förvar>.push anger en annan <mål>. Till exempel, om main är en gren, expanderas refspec main till main:refs/heads/main.

  • Om <mål> otvetydigt refererar till en referens på fjärr <förvar>, expandera den till den referensen. Om till exempel v1.0 är en tagg på fjärren, expanderas HEAD:v1.0 till HEAD:refs/tags/v1.0.

  • Om <src> leder till en referens som börjar med refs/heads/ eller refs/tags/, lägg då till det före <mål>. Om till exempel main är en gren, expanderas main:other till main:refs/heads/other

  • Den speciella refspecen : (eller +: för att tillåta uppdateringar som inte spolas framåt) instruerar Git att skicka "matchande" grenar: för varje gren som finns på den lokala sidan uppdateras fjärrsidan om en gren med samma namn redan finns på fjärrsidan.

  • <src> kan innehålla ett * för att indikera en enkel mönstermatchning. Detta fungerar som en glob som matchar alla referenser som matchar mönstret. Det får bara finnas ett * i både <src> och <mål>. Den kommer att mappa referenser till målet genom att ersätta * med innehållet som matchas från källan. Till exempel kommer refs/heads/*:refs/heads/* att sända alla grenar.

  • En refspec som börjar med ^ är en negativ refspec. Detta anger 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 mönsterrefspecs. De får bara innehålla ett <src>. Fullständigt stavade hexadecimala objektnamn stöds inte heller. Till exempel kommer git push origin refs/heads/*' ^refs/heads/dev-*' att pusha alla grenar förutom de som börjar med dev-

  • Om <src> är tomt, raderas <mål>-referensen från fjärrförvar. Till exempel, git push origin :dev kommer att radera dev-grenen.

  • tag <tagg> expanderar till refs/tags/<tagg>:refs/tags/<tagg>. Detta är tekniskt sett en speciell syntax för git push och inte en refspec, eftersom argumenten tag och v1.0 är separata i git push origin tag v1.0.

  • Om refspec:en inte kan expanderas entydigt, skicka ett felmeddelande som anger vad som försöktes, och beroende på konfigurationen av advice.pushUnqualifiedRefname (se git-config[1]) föreslå vilken refs/namnrymd du kanske ville skicka till.

Inte alla uppdateringar är tillåtna: se SÄND-REGLER nedan för mer information.

--all
--branches

Skjut alla grenar (dvs. refs under refs/heads/); kan inte användas med andra <refspec>.

--prune

Ta bort fjärrgrenar som inte har en lokal motsvarighet. Till exempel kommer en fjärrgren tmp att tas bort om en lokal gren med samma namn inte längre finns. Detta respekterar även refspecs, t.ex. git push --prune remote refs/heads/*:refs/tmp/* skulle se till att fjärrgrenen refs/tmp/foo kommer att tas bort om refs/heads/foo inte finns.

--mirror

Istället för att namnge varje referens att pusha, anger detta att alla referenser under refs/ (vilket inkluderar men inte är begränsat till refs/heads/, refs/remotes/ och refs/tags/) ska speglas till fjärrförvar. Nyskapade lokala referenser kommer att pushas till fjärrändan, lokalt uppdaterade referenser kommer att tvångsuppdateras på fjärrändan och borttagna referenser kommer att tas bort från fjärrändan. Detta är standardinställningen om konfigurationsalternativet remote.<fjärr>.mirror är inställt.

-n
--dry-run

Gör allt utom att faktiskt skicka uppdateringarna.

--porcelain

Producera maskinläsbar utdata. Statusraden för varje referens kommer att vara tabbaseparerad och skickas till stdout istället för stderr. De fullständiga symboliska namnen på referenserna kommer att anges.

-d
--delete

Alla listade referenser raderas från fjärrförvar. Detta är samma sak som att lägga till ett kolon före alla referenser.

--tags

Alla referenser under refs/tags skickas, utöver refspecs som uttryckligen listas på kommandoraden.

--follow-tags

Skicka alla referenser som skulle skickas utan det här alternativet, och skicka även kommenterade taggar i refs/tags som saknas i fjärren men pekar på inchecknings-aktig och som kan nås från de referenser som skickas. Detta kan också anges med konfigurationsvariabeln push.followTags. För mer information, se push.followTags i git-config[1].

--signed
--no-signed
--signed=(true|false|if-asked)

GPG-signera sänd-begäran för att uppdatera referenser på mottagarsidan, så att den kan kontrolleras av krokarna och/eller loggas. Möjliga värden är:

false
--no-signed

inget försök till signering kommer att göras.

true
--signed

Push-funktionen kommer att misslyckas om servern inte stöder signerade push-meddelanden.

if-asked

signera om och endast om servern stöder signerade push-kommandon. Push-kommandot kommer också att misslyckas om det faktiska anropet till gpg --sign misslyckas. Se git-receive-pack[1] för detaljer om mottagarsidan.

--atomic
--no-atomic

Använd en atomär transaktion på fjärrsidan om sådan finns. Antingen uppdateras alla referenser, eller vid fel uppdateras inga referenser. Om servern inte stöder atomära push-transaktioner kommer push-transaktionen att misslyckas.

-o <alternativ>
--push-option=<alternativ>

Skicka den givna strängen till servern, som skickar dem till både pre-receive- och post-receive-kroken. Den givna strängen får inte innehålla tecknet NUL eller LF. När flera --push-option=<alternativ> anges skickas de alla till den andra sidan i den ordning som anges på kommandoraden. När ingen --push-option=<alternativ> anges från kommandoraden används värdena för konfigurationsvariabeln push.pushOption istället.

--receive-pack=<git-receive-pack>
--exec=<git-receive-pack>

Path to the git-receive-pack program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH.

--force-with-lease
--no-force-with-lease
--force-with-lease=<refnamn>
--force-with-lease=<refnamn>:<förväntat>

Vanligtvis vägrar git push att uppdatera en fjärrreferens som inte är en förfader till den lokala referensen som används för att skriva över den.

Det här alternativet åsidosätter denna begränsning om det aktuella värdet för fjärrreferensen är det förväntade värdet. git push misslyckas annars.

Tänk dig att du måste återanvända det du redan har publicerat. Du måste kringgå regeln "måste spola framåt" för att ersätta den historik du ursprungligen publicerade med den återanvända historiken. Om någon annan byggde ovanpå din ursprungliga historik medan du återanvänder den, kan toppen av grenen på fjärrkontrollen gå vidare med sin incheckning, och att blint trycka på --force kommer att förlora sitt arbete.

Det här alternativet låter dig ange att du förväntar dig att historiken du uppdaterar är den du ombaserade och vill ersätta. Om fjärrreferensen fortfarande pekar på den incheckning du angav, kan du vara säker på att inga andra personer gjorde något med referensen. Det är som att ta ett "leaseavtal" på referensen utan att explicit låsa den, och fjärrreferensen uppdateras bara om "leaseavtalet" fortfarande är giltigt.

Enbart --force-with-lease, utan att specificera detaljerna, kommer att skydda alla fjärrreferenser som ska uppdateras genom att kräva att deras nuvarande värde är detsamma som den fjärrspårningsgren vi har för dem.

--force-with-lease=<refname>, without specifying the expected value, will protect <refname> (alone), if it is going to be updated, by requiring its current value to be the same as the remote-tracking branch we have for it.

--force-with-lease=<refnamn>:<förväntat> skyddar <refnamn> (ensamt), om den ska uppdateras, genom att kräva att dess nuvarande värde är detsamma som det angivna värdet <förväntat> (vilket tillåts skilja sig från den fjärrspårningsgren vi har för refnamen, annars behöver vi inte ens ha en sådan fjärrspårningsgren när denna form används). Om <förväntat> är den tomma strängen, får den namngivna refen inte redan existera.

Observera att alla former förutom --force-with-lease=<refnamn>:<förväntat> som explicit anger det förväntade aktuella värdet för referensen fortfarande är experimentella och deras semantik kan komma att ändras allt eftersom vi får erfarenhet av den här funktionen.

--no-force-with-lease kommer att upphäva alla tidigare --force-with-lease på kommandoraden.

En allmän anmärkning om säkerhet: att ange detta alternativ utan ett förväntat värde, dvs. som --force-with-lease eller --force-with-lease=<refnamn>, interagerar mycket dåligt med allt som implicit kör git fetch på fjärren för att skickas till i bakgrunden, t.ex. git fetch origin på ditt förvar i ett cronjob.

Skyddet den erbjuder jämfört med --force säkerställer att efterföljande ändringar som ditt arbete inte baserades på inte förstörs, men detta är trivialt om någon bakgrundsprocess uppdaterar referenser i bakgrunden. Vi har inget annat än fjärrspårningsinformation att använda som en heuristik för referenser som du förväntas ha sett och är villig att förstöra.

Om din editor eller något annat system kör git fetch i bakgrunden är ett sätt att mildra detta att helt enkelt konfigurera en annan fjärr:

git remote add origin-push $(git config remote.origin.url)
git fetch origin-push

När bakgrundsprocessen kör git fetch origin kommer referenserna på origin-push inte att uppdateras, och därmed kommandon som:

git push --force-with-lease origin-push

Kommer att misslyckas om du inte kör git fetch origin-push manuellt. Den här metoden är naturligtvis helt omintetgjord av något som kör git fetch --all, i så fall skulle du behöva antingen inaktivera den eller göra något mer mödosamt som:

git fetch              # uppdatera 'master' från fjärr
git tag base master    # markera vår baspunktt
git rebase -i master   # skriv om några incheckningar
git push --force-with-lease=master:base master:master

Dvs. skapa en base-tagg för versioner av uppströmskoden som du har sett och är villig att skriva över, skriv sedan om historiken, och tvinga slutligen fram sänd-ändringar till master om fjärrversionen fortfarande är på base, oavsett vad din lokala remotes/origin/master har uppdaterats till i bakgrunden.

Alternativt kan man ange --force-if-includes som ett tilläggsalternativ tillsammans med --force-with-lease[=<refnamn>] (dvs. utan att ange exakt vilken incheckning referensen på fjärrsidan måste peka på, eller vilka referenser på fjärrsidan som skyddas) vid tidpunkten för "sändningen" för att verifiera om uppdateringar från fjärrspårningsreferenserna som kan ha uppdaterats implicit i bakgrunden integreras lokalt innan en tvångsuppdatering tillåts.

-f
--force

Vanligtvis vägrar git push att uppdatera en branch som inte är en förfader till den incheckning som sändas.

Denna flagga inaktiverar den kontrollen, de andra säkerhetskontrollerna i SÄND REGLER nedan och kontrollerna i --force-with-lease. Det kan orsaka att fjärrarkivet förlorar incheckningar; använd den med försiktighet.

Observera att --force gäller för alla referenser som skickas, därför kan användning med push.default inställd på matching eller med flera sänd-destinationer konfigurerade med remote.<namn>.push skriva över andra referenser än den aktuella grenen (inklusive lokala referenser som ligger strikt efter deras fjärrmotsvarighet). För att tvinga fram en sändning till endast en gren, använd ett + framför refspec:en för att skicka (t.ex. git push origin +master för att tvinga fram en sända till grenen master). Se avsnittet <refspec>... ovan för mer information.

--force-if-includes
--no-force-if-includes

Tvinga fram en uppdatering endast om toppen på fjärrspårningsreferensen har integrerats lokalt.

Det här alternativet aktiverar en kontroll som verifierar om toppen för fjärrspårningsreferensen är nåbar från en av "reflog"-posterna för den lokala grenen som är baserad i den för en omskrivning. Kontrollen säkerställer att eventuella uppdateringar från fjärren har införlivats lokalt genom att avvisa den påtvingade uppdateringen om så inte är fallet.

Om alternativet skickas utan att ange --force-with-lease, eller anges tillsammans med --force-with-lease=<refnamn>:<förvätat>, är det en "no-op".

Om du anger --no-force-if-includes inaktiveras detta beteende.

--repo=<förvar>

Det här alternativet motsvarar argumentet <förvar>. Om båda anges har kommandoradsargumentet företräde.

-u
--set-upstream

För varje branch som är uppdaterad eller har sänts, 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 i git-config[1].

--thin
--no-thin

Dessa alternativ skickas till git-send-pack[1]. En tunn överföring minskar mängden skickad data avsevärt när sändare och mottagare delar många av samma objekt gemensamt. Standardvärdet är --thin.

-q
--quiet

Undertryck all utdata, inklusive listan över uppdaterade referenser, såvida inte ett fel uppstår. Förlopp rapporteras inte till standardfelströmmen.

-v
--verbose

Kör utförligt.

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

--no-recurse-submodules
--recurse-submodules=(check|on-demand|only|no)

Kan användas för att säkerställa att alla undermodul-incheckningar som används av de revisioner som ska sänds är tillgängliga på en fjärrspårningsgren. Möjliga värden är:

check

Git kommer att verifiera att alla undermodul-incheckningar som ändrats i de revisioner som ska sändas är tillgängliga på minst en fjärr till undermodulen. Om några incheckningar saknas kommer sänd-processen att avbrytas och avslutas med status som inte är noll.

on-demand

alla undermoduler som ändrats i de revisioner som ska skickas kommer att skickas. Om on-demand inte kunde skicka alla nödvändiga revisioner kommer den också att avbrytas och avslutas med status som inte är noll.

only

Alla undermoduler kommer att skickas medan superprojektet lämnas oskickat.

no

åsidosätta konfigurationsvariabeln push.recurseSubmodules när ingen rekursion av en undermodul krävs. Liknar det att använda --no-recurse-submodules.

När on-demand eller only används, om en undermodul har en push.recurseSubmodules=(on-demand|only) eller submodule.recurse konfiguration, kommer ytterligare rekursion att ske. I det här fallet behandlas only som on-demand.

--verify
--no-verify

Aktivera pre-push-kroken (se githooks[5]). Standardinställningen är --verify, vilket ger kroken en chans att förhindra sänd-funktionen. Med --no-verify kringgås kroken helt.

-4
--ipv4

Använd endast IPv4-adresser och ignorera IPv6-adresser.

-6
--ipv6

Använd endast IPv6-adresser och ignorera IPv4-adresser.

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".

UTMATNING

Utdata från "git push" beror på vilken transportmetod som används; det här avsnittet beskriver utdata vid pushing av Git-protokollet (antingen lokalt eller via ssh).

Statusen för sänd-funktionen visas i tabellform, där varje rad representerar statusen för en enskild referens. Varje rad har formen:

 <flagga> <sammanfattning> <från> -> <till> (<orsak>)

Om --porcelain används, så är varje rad i utdata av formen:

 <flagga> \t <från>:<till> \t <sammanfattning> (<orsak>)

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

<flagga>

Ett enda tecken som anger referensens status:

(mellanslag)

för en framgångsrikt sänt snabbspolning;

+

för en lyckad påtvingad uppdatering;

-

för en framgångsrikt borttagen ref;

*

för en framgångsrikt sänt ny ref;

!

för en ref som avvisades eller misslyckades med att sändas; och

=

för en ref som var aktuell och inte behövde sändas.

<sammanfattning>

För en lyckat sänt 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 <gamla>..<nya> i de flesta fall, och <gamla>...<nya> för tvingade uppdateringar som inte snabbspolas framåt).

För en misslyckad uppdatering ges mer information:

rejected

Git försökte inte skicka referensen alls, vanligtvis för att det inte är en snabbspolning framåt och du inte tvingade fram uppdateringen.

fjärren avvisad

Fjärrsidan vägrade uppdateringen. Vanligtvis orsakat av en krok på fjärrsidan, eller att fjärrförvar har ett av följande säkerhetsalternativ aktiverat: receive.denyCurrentBranch (för sänd-besked till den utcheckade grenen), receive.denyNonFastForwards (för tvingade uppdateringar som inte snabbspolas framåt), receive.denyDeletes eller receive.denyDeleteCurrent. Se git-config[1].

fjärrfel

Fjärrsidan rapporterade inte att uppdateringen av referensen lyckades, kanske på grund av ett tillfälligt fel på fjärrsidan, ett avbrott i nätverksanslutningen eller annat övergående fel.

från

Namnet på den lokala referens som skickas, minus dess prefix refs/<typ>/. Vid borttagning utelämnas namnet på den lokala referensen.

till

Namnet på den fjärrreferens som uppdateras, minus dess prefix refs/<typ>/.

skäl

En människoläsbar förklaring. Vid framgångsrikt skickad ref, behövs ingen förklaring. För en misslyckad ref, beskrivs orsaken till misslyckandet.

SÄND REGLER

Som en säkerhetsfunktion tillåter kommandot git push endast vissa typer av uppdateringar för att förhindra att du av misstag förlorar data på fjärren.

Eftersom grenar och taggar är avsedda att användas på olika sätt, skiljer sig säkerhetsreglerna för att pusha till en gren från reglerna för att pusha till en tagg. I följande regler betyder "uppdatering" alla modifieringar förutom borttagningar och skapande. Borttagningar och skapande är alltid tillåtna, förutom när det är förbjudet enligt konfiguration eller krokar.

  1. Om sänd-destinationen är en branch (refs/heads/*): är endast snabbspolningsuppdateringar tillåtna, vilket innebär att destinationen måste vara en förfader till käll-incheckningen. Källan måste vara en incheckningen.

  2. Om sänd-destinationen är en tagg (refs/tags/*): kommer alla uppdateringar att avvisas. Källan kan vara vilket objekt som helst.

  3. Om sänd-destinationen inte är en gren eller tagg:

    • Om källan är ett träd- eller blobobjekt kommer alla uppdateringar att avvisas

    • Om källan är ett tagg- eller inchecknings-objekt är alla snabbspolningsuppdateringar tillåtna, även i fall där det som snabbspolas framåt inte är en incheckning, utan ett tagg-objekt som råkar peka på en ny incheckning som är en snabbspolning framåt jämfört med den incheckning som den sista taggen (eller incheckning) den ersätter. Att ersätta en tagg med en helt annan tagg är också tillåtet, om den pekar på samma incheckning, samt att skicka ("pusha") en skalad tagg, dvs. att skicka den incheckning som ett befintligt tagg-objekt pekar på, eller ett nytt tagg-objekt som ett befintligt incheckning pekar på.

Du kan åsidosätta dessa regler genom att skicka --force eller genom att lägga till det valfria inledande + till en refspec. De enda undantagen är att ingen mängd tvång kommer att få en gren att acceptera ett icke-inchecknings-objekt, och tvång kommer inte att få fjärrförvar att acceptera en sänding som det är konfigurerat att neka.

Krokar och konfiguration kan också åsidosätta eller ändra dessa regler, se t.ex. receive.denyNonFastForwards och receive.denyDeletes i git-config[1] och pre-receive och update i githooks[5].

NOTERING OM SNABBSPOLNING FRAMÅT

När en uppdatering ändrar en gren (eller mer generellt, en referens) som brukade peka på incheckning A till att peka på en annan incheckning B, kallas det en snabbuppdatering om och endast om B är en ättling incheckning A.

I en snabbspolning från A till B är uppsättningen incheckningar som den ursprungliga incheckning A byggde ovanpå en delmängd av de incheckningar som den nya incheckning B bygger ovanpå. Därför förlorar den ingen historik.

Däremot, kommer en uppdatering som inte spolas framåt att förlora historik. Anta till exempel, att du och någon annan började vid samma incheckning X, och ni byggde en historik som ledde till incheckning B medan den andra personen byggde en historik som ledde till incheckning A. Historiken ser ut så här:

      B
     /
 ---X---A

Anta vidare att den andra personen redan sände ändringar som leder till A tillbaka till det ursprungliga förvaret från vilket ni två hämtade den ursprungliga incheckningen X.

Sändningen som den andra personen gjorde uppdaterade grenen som brukade peka på commit X till att peka på commit A. Det är en snabbspolning framåt.

Men om du försöker sända ("pusha"), kommer du att försöka uppdatera grenen (som nu pekar på A) med commit B. Detta spola inte framåt. Om du gjorde det kommer ändringarna som introducerades av incheckning A att gå förlorade, eftersom alla nu kommer att börja bygga ovanpå B.

Kommandot tillåter som standard inte en uppdatering som inte är en snabbspolning framåt för att förhindra sådan historikförlust.

Om du inte vill förlora ditt arbete (historik från X till B) eller arbetet av den andra personen (historik från X till A), måste du först hämta historiken från förvaret, skapa en historik som innehåller ändringar gjorda av båda parter och sedan spara resultatet.

Du kan utföra "git pull", lösa potentiella konflikter och "git push" resultatet. En "git pull" skapar en sammanslagins-incheckning C mellan incheckningar A och B.

      B---C
     /   /
 ---X---A

Att uppdatera A med den resulterande sammanslagings-incheckning kommer att snabbspola framåt och din sändingen kommer att accepteras.

Alternativt kan du återanvända din ändring mellan X och B ovanpå A, med git pull --rebase, och sända resultatet tillbaka. Ombasering skapar en ny incheckning D som bygger ändringen mellan X och B ovanpå A.

      B   D
     /   /
 ---X---A

Återigen, om du uppdaterar A med denna incheckning kommer det att snabbspola framåt och din sändning kommer att accepteras.

Det finns en annan vanlig situation där du kan stöta på avslag utan snabbspolning framåt när du försöker sända, och det är möjligt även när du sänder in i ett förvar som ingen annan sänder i. Efter att du själv sänder incheckning A (i den första bilden i det här avsnittet), ersätt det med git commit --amend för att producera commit B, och du försöker sända ut det, eftersom du glömt att du redan har sändt A. I ett sådant fall, och bara om du är säker på att ingen under tiden hämtade din tidigare incheckning A (och började bygga ovanpå den), kan du köra git push --force för att skriva över den. Med andra ord, git push --force är en metod reserverad för ett fall där du avser att förlora historik.

EXEMPEL

git push

Fungerar som git push <fjärr>, där <fjärr> är den aktuella grenens fjärr(eller origin, om ingen fjärr är konfigurerad för den aktuella grenen).

git push origin

Utan ytterligare konfiguration, skickas den aktuella grenen till den konfigurerade uppströmsen (konfigurationsvariabeln branch.<namn>.merge) om den har samma namn som den aktuella grenen, och felmeddelanden utfärdas utan att skicka något annat.

Standardbeteendet för det här kommandot när ingen <refspec> anges kan konfigureras genom att ställa in alternativet push på fjärrkontrollen eller konfigurationsvariabeln push.default.

Till exempel, för att som standard bara pusha den aktuella grenen till origin, använd git config remote.origin.push HEAD. Vilken giltig <refspec> som helst (som de i exemplen nedan) kan konfigureras som standard för git push origin.

git push origin :

Skjut "matchande" grenar till origin. Se <refspec> i avsnittet FLAGGOR ovan för en beskrivning av "matchande" grenar.

git push origin master

Hitta en referens som matchar master i käll-förvaret (troligtvis skulle den hitta refs/heads/master), och uppdatera samma referens (t.ex. refs/heads/master) i origin-förrådet med den. Om master inte existerade på distans skulle den skapas.

git push origin HEAD

Ett praktiskt sätt att sända den aktuella grenen till samma namn på fjärren.

git push moderskepp master:satellit/master dev:satellit/dev

Använd källreferensen som matchar master (t.ex. refs/heads/master) för att uppdatera referensen som matchar satellit/master (troligtvis refs/remotes/satellit/master) i moderskepp-förvaret; gör detsamma för dev och satellite/dev.

Se avsnittet som beskriver <refspec>... ovan för en diskussion om matchande semantik.

Detta är för att emulera git fetch som körs på moderskeppet med hjälp av git push som körs i motsatt riktning för att integrera arbetet som utförs på satellit, och är ofta nödvändigt när man bara kan upprätta anslutning på ett sätt (dvs. satelliten kan ssh in i moderskeppet men moderskeppet kan inte initiera anslutning till satelliten eftersom den senare är bakom en brandvägg eller inte kör sshd).

Efter att ha kört denna git push på satellit-maskinen, skulle du ssh-a in i moderskepp och köra git merge där för att slutföra emuleringen av git pull som kördes på moderskepp för att hämta ändringar gjorda på satellit.

git push origin HEAD:master

Skicka den aktuella grenen till fjärrreferensen som matchar master i origin-förvaret. Den här formen är bekväm för att skicka den aktuella grenen utan att behöva tänka på dess lokala namn.

git push origin master:refs/heads/experimentell

Skapa grenen experimentell i origin-arkivet genom att kopiera den aktuella master-grenen. Detta formulär behövs bara för att skapa en ny gren eller tagg i fjärr-förvaret när det lokala namnet och fjärrnamnet är olika; annars fungerar referensnamnet på egen hand.

git push origin :experimentell

Hitta en referens som matchar experimentell i origin-förvaret (t.ex. refs/heads/experimentell) och radera den.

git push origin +dev:master

Update the origin repository’s master branch with the dev branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository. Consider the following situation, where a fast-forward is not possible:

	    o---o---o---A---B  origin/master
		     \
		      X---Y---Z  dev

Ovanstående kommando skulle ändra ursprungs-förvaret till

		      A---B  (namnlös gren)
		     /
	    o---o---o---X---Y---Z  master

Incheckning A och B skulle inte längre tillhöra en gren med ett symboliskt namn, och skulle därför vara oåtkomliga. Som sådan skulle dessa incheckningar tas bort med ett git gc-kommando i ursprungsförrådet.

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/push.adoc

See original version for this content.

GIT

En del av git[1]-sviten