Git

git-push zuletzt aktualisiert in 2.52.0

NAME

git-push - Remote-Referenzen zusammen mit zugehörigen Objekten aktualisieren

SYNOPSIS

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

BESCHREIBUNG

Aktualisiert eine oder mehrere Branches, Tags oder andere Referenzen in einem Remote-Repository aus Ihrem lokalen Repository und sendet alle notwendigen Daten, die noch nicht auf dem Remote-System vorhanden sind.

Der einfachste Weg zu pushen ist git push <remote> <branch>. git push origin main pusht den lokalen main Branch zum main Branch auf dem Remote namens origin.

Das Argument <repository> wird standardmäßig auf das Upstream des aktuellen Branches gesetzt oder auf origin, wenn kein konfiguriertes Upstream vorhanden ist.

Um zu entscheiden, welche Branches, Tags oder andere Refs gepusht werden sollen, verwendet Git (in absteigender Reihenfolge der Priorität):

Die Argumente <refspec> (zum Beispiel main in git push origin main) oder die Optionen --all, --mirror oder --tags.
Die Konfiguration remote.*.push für das Repository, zu dem gepusht wird.
Die Konfiguration push.default. Der Standardwert ist push.default=simple, was zu einem Branch mit demselben Namen wie der aktuelle Branch pusht. Weitere Informationen zu push.default finden Sie im Abschnitt KONFIGURATION weiter unten.

git push kann fehlschlagen, wenn Sie kein Upstream für den aktuellen Branch festgelegt haben, abhängig davon, wie push.default eingestellt ist. Informationen zum Festlegen und Verwenden von Upstreams finden Sie im Abschnitt UPSTREAM-BRANCHES weiter unten.

Sie können interessante Dinge mit einem Repository tun lassen, jedes Mal wenn Sie etwas hinein pushen, indem Sie dort Hooks einrichten. Siehe Dokumentation für git-receive-pack[1].

OPTIONEN

<repository>

Das "Remote"-Repository, das das Ziel einer Push-Operation ist. Dieses Argument kann entweder eine URL sein (siehe den Abschnitt GIT URLS unten) oder der Name eines Remotes (siehe den Abschnitt REMOTES unten).

<refspec>…

Geben Sie an, welche Zielreferenz mit welchem Quellobjekt aktualisiert werden soll.

Das Format für einen Refspec ist [+]<src>[:<dst>], zum Beispiel main, main:other oder HEAD^:refs/heads/main.

Der <src> ist oft der Name des lokalen Branches, der gepusht wird, kann aber auch ein beliebiger "SHA-1-Ausdruck" sein (siehe gitrevisions[7]).

Der <dst> bestimmt, welche Referenz auf der Remote-Seite aktualisiert wird. Es muss der Name eines Branches, Tags oder einer anderen Referenz sein, keine beliebige Zeichenkette.

Das + ist optional und bewirkt dasselbe wie --force.

Sie können einen Refspec mit der vollständig ausgeschriebenen Form schreiben (z.B. refs/heads/main:refs/heads/main), die die genaue Quelle und das genaue Ziel angibt, oder mit einer kürzeren Form (z.B. main oder main:other). Hier sind die Regeln, wie Refspecs erweitert werden, sowie verschiedene andere spezielle Refspec-Formen:

<src> ohne :<dst> bedeutet, dass dieselbe Referenz wie die <src> aktualisiert wird, es sei denn, die Konfiguration remote.<repository>.push gibt eine andere <dst> an. Wenn z.B. main ein Branch ist, dann expandiert der Refspec main zu main:refs/heads/main.
Wenn <dst> eindeutig auf eine Referenz im Remote-Repository <repository> verweist, dann erweitern Sie sie zu dieser Referenz. Wenn z.B. v1.0 ein Tag auf dem Remote ist, dann expandiert HEAD:v1.0 zu HEAD:refs/tags/v1.0.
Wenn <src> zu einer Referenz aufgelöst wird, die mit refs/heads/ oder refs/tags/ beginnt, dann fügen Sie diese dem <dst> voran. Wenn z.B. main ein Branch ist, dann expandiert main:other zu main:refs/heads/other.
Der spezielle Refspec : (oder +: um Nicht-Fast-Forward-Updates zu erlauben) weist Git an, "passende" Branches zu pushen: Für jeden Branch, der auf der lokalen Seite existiert, wird die Remote-Seite aktualisiert, wenn ein Branch mit demselben Namen auf der Remote-Seite bereits existiert.
<src> kann ein * enthalten, um eine einfache Musterübereinstimmung anzuzeigen. Dies funktioniert wie ein Glob, der jede Referenz abgleicht, die dem Muster entspricht. Es darf nur ein * sowohl in der <src> als auch in der <dst> geben. Es ordnet Referenzen dem Ziel zu, indem es das * durch den Inhalt ersetzt, der aus der Quelle abgeglichen wurde. Zum Beispiel wird refs/heads/*:refs/heads/* alle Branches pushen.
Ein Refspec, der mit ^ beginnt, ist ein negativer Refspec. Dieser gibt Referenzen an, die ausgeschlossen werden sollen. Eine Referenz wird als passend betrachtet, wenn sie mindestens einem positiven Refspec entspricht und keinem negativen Refspec entspricht. Negative Refspecs können Muster-Refspecs sein. Sie dürfen nur ein <src> enthalten. Vollständig ausgeschriebene Hex-Objekt-Namen werden ebenfalls nicht unterstützt. Zum Beispiel wird git push origin refs/heads/*' ^refs/heads/dev-*' alle Branches pushen, außer denen, die mit dev- beginnen.
Wenn <src> leer ist, wird die <dst> Referenz aus dem Remote-Repository gelöscht. Zum Beispiel wird git push origin :dev den dev Branch löschen.
tag <tag> expandiert zu refs/tags/<tag>:refs/tags/<tag>. Dies ist technisch gesehen eine spezielle Syntax für git push und kein Refspec, da in git push origin tag v1.0 die Argumente tag und v1.0 separat sind.
Wenn der Refspec nicht eindeutig erweitert werden kann, geben Sie einen Fehler aus, der angibt, was versucht wurde, und schlagen Sie je nach Konfiguration advice.pushUnqualifiedRefname (siehe git-config[1]) die gewünschte Referenz-Namensraum vor, zu dem Sie pushen wollten.

Nicht alle Updates sind erlaubt: siehe PUSH REGELN unten für die Details.

--all

--branches

Pusht alle Branches (d.h. Referenzen unter refs/heads/); kann nicht mit anderen <refspec> verwendet werden.

--prune

Entfernt Remote-Branches, die kein lokales Gegenstück haben. Zum Beispiel wird ein Remote-Branch tmp entfernt, wenn kein lokaler Branch mit demselben Namen mehr existiert. Dies berücksichtigt auch Refspecs, z.B. git push --prune remote refs/heads/*:refs/tmp/* stellt sicher, dass refs/tmp/foo auf dem Remote entfernt wird, wenn refs/heads/foo nicht existiert.

--mirror

Anstatt jeden zu pushenden Ref zu benennen, gibt dies an, dass alle Referenzen unter refs/ (was nicht nur refs/heads/, refs/remotes/ und refs/tags/ einschließt) in das Remote-Repository gespiegelt werden sollen. Neu erstellte lokale Referenzen werden am Remote-Ende gepusht, lokal aktualisierte Referenzen werden am Remote-Ende mit Gewalt aktualisiert und gelöschte Referenzen werden vom Remote-Ende entfernt. Dies ist der Standard, wenn die Konfigurationsoption remote.<remote>.mirror gesetzt ist.

-n

--dry-run

Tut alles außer dem tatsächlichen Senden der Updates.

--porcelain

Erzeugt maschinenlesbare Ausgabe. Die Statuszeile für jeden Ref wird mit Tabulatoren getrennt und an stdout statt an stderr gesendet. Die vollständigen symbolischen Namen der Refs werden angegeben.

-d

--delete

Alle aufgelisteten Refs werden aus dem Remote-Repository gelöscht. Dies ist dasselbe wie das Voranstellen eines Doppelpunkts vor allen Refs.

--tags

Alle Referenzen unter refs/tags werden gepusht, zusätzlich zu den explizit in der Befehlszeile aufgeführten Refspecs.

--follow-tags

Pusht alle Referenzen, die ohne diese Option gepusht würden, und pusht auch annotierte Tags in refs/tags, die auf dem Remote fehlen, aber auf Commit-Objekte zeigen, die von den zu pushenden Referenzen erreichbar sind. Dies kann auch über die Konfigurationsvariable push.followTags festgelegt werden. Weitere Informationen finden Sie unter push.followTags in git-config[1].

--signed

--no-signed

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

GPG-signieren Sie die Push-Anfrage, um Refs auf der Empfängerseite zu aktualisieren, damit sie von den Hooks überprüft und/oder protokolliert werden können. Wenn false oder --no-signed, wird keine Signierung versucht. Wenn true oder --signed, schlägt der Push fehl, wenn der Server keine signierten Pushes unterstützt. Wenn auf if-asked gesetzt, wird signiert, wenn und nur wenn der Server signierte Pushes unterstützt. Der Push schlägt auch fehl, wenn der tatsächliche Aufruf von gpg --sign fehlschlägt. Details auf der Empfängerseite finden Sie in git-receive-pack[1].

--atomic

--no-atomic

Verwenden Sie eine atomare Transaktion auf der Remote-Seite, falls verfügbar. Entweder werden alle Refs aktualisiert, oder im Fehlerfall werden keine Refs aktualisiert. Wenn der Server keine atomaren Pushes unterstützt, schlägt der Push fehl.

-o <option>

--push-option=<option>

Überträgt die angegebene Zeichenkette an den Server, der sie an die pre-receive und post-receive Hooks weitergibt. Die angegebene Zeichenkette darf kein NUL- oder LF-Zeichen enthalten. Wenn mehrere --push-option=<option> angegeben werden, werden sie alle in der auf der Befehlszeile aufgeführten Reihenfolge an die andere Seite gesendet. Wenn von der Befehlszeile keine --push-option=<option> angegeben wird, werden stattdessen die Werte der Konfigurationsvariablen push.pushOption verwendet.

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

--exec=<git-receive-pack>

Pfad zum Programm git-receive-pack auf der Remote-Seite. Manchmal nützlich beim Pushen zu einem Remote-Repository über SSH, und Sie haben das Programm nicht in einem Verzeichnis im Standard-$PATH.

--force-with-lease

--no-force-with-lease

--force-with-lease=<refname>

--force-with-lease=<refname>:<expect>

Normalerweise weigert sich "git push", eine Remote-Referenz zu aktualisieren, die kein Vorfahre der lokalen Referenz ist, die zum Überschreiben verwendet wird.

Diese Option überschreibt diese Einschränkung, wenn der aktuelle Wert der Remote-Referenz der erwartete Wert ist. "git push" schlägt andernfalls fehl.

Stellen Sie sich vor, Sie müssen etwas rebasen, das Sie bereits veröffentlicht haben. Sie müssen die Regel "muss ein Fast-Forward sein" umgehen, um die ursprünglich veröffentlichte Historie durch die gerebasete Historie zu ersetzen. Wenn jemand anderes auf Ihrer ursprünglichen Historie aufgebaut hat, während Sie rebasen, kann sich die Spitze des Branches auf dem Remote mit seinem Commit verschoben haben, und ein blindes Pushen mit --force wird seine Arbeit verlieren.

Diese Option erlaubt es Ihnen zu sagen, dass Sie erwarten, dass die zu aktualisierende Historie diejenige ist, die Sie rebasen und ersetzen möchten. Wenn die Remote-Referenz immer noch auf den Commit zeigt, den Sie angegeben haben, können Sie sicher sein, dass niemand anderes etwas an der Referenz geändert hat. Es ist wie eine "Lease" auf die Referenz zu nehmen, ohne sie explizit zu sperren, und die Remote-Referenz wird nur aktualisiert, wenn die "Lease" noch gültig ist.

--force-with-lease allein, ohne Angabe der Details, schützt alle Remote-Referenzen, die aktualisiert werden sollen, indem verlangt wird, dass ihr aktueller Wert derselbe ist wie der Remote-Tracking-Branch, den wir für sie haben.

--force-with-lease=<refname>, ohne den erwarteten Wert anzugeben, schützt die benannte Referenz (alleine), wenn sie aktualisiert werden soll, indem verlangt wird, dass ihr aktueller Wert derselbe ist wie der Remote-Tracking-Branch, den wir für sie haben.

--force-with-lease=<refname>:<expect> schützt die benannte Referenz (alleine), wenn sie aktualisiert werden soll, indem verlangt wird, dass ihr aktueller Wert derselbe ist wie der angegebene Wert <expect> (der sich vom Remote-Tracking-Branch, den wir für den Refnamen haben, unterscheiden kann, oder wir müssen nicht einmal einen solchen Remote-Tracking-Branch haben, wenn diese Form verwendet wird). Wenn <expect> eine leere Zeichenkette ist, dann darf die benannte Referenz noch nicht existieren.

Beachten Sie, dass alle Formen außer --force-with-lease=<refname>:<expect>, die den erwarteten aktuellen Wert der Referenz explizit angibt, noch experimentell sind und ihre Semantik sich ändern kann, wenn wir Erfahrungen mit dieser Funktion sammeln.

"--no-force-with-lease" bricht alle vorherigen --force-with-lease auf der Befehlszeile ab.

Eine allgemeine Anmerkung zur Sicherheit: Das Angeben dieser Option ohne erwarteten Wert, d.h. als --force-with-lease oder --force-with-lease=<refname>, interagiert sehr schlecht mit allem, was implizit git fetch auf dem zu pushenden Remote im Hintergrund ausführt, z.B. git fetch origin in Ihrem Repository per Cronjob.

Der Schutz, den es über --force hinaus bietet, besteht darin, sicherzustellen, dass nachfolgende Änderungen, auf denen Ihre Arbeit nicht basierte, nicht überschrieben werden, aber dies wird trivial durchbrochen, wenn ein Hintergrundprozess Refs im Hintergrund aktualisiert. Wir haben nichts außer den Remote-Tracking-Informationen als Heuristik für Refs, die Sie gesehen haben sollten & bereit sind zu überschreiben.

Wenn Ihr Editor oder ein anderes System git fetch im Hintergrund für Sie ausführt, ist eine Möglichkeit, dies abzumildern, einfach ein weiteres Remote einzurichten

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

Nun, wenn der Hintergrundprozess git fetch origin ausführt, werden die Referenzen auf origin-push nicht aktualisiert, und daher Befehle wie

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

werden fehlschlagen, es sei denn, Sie führen manuell git fetch origin-push aus. Diese Methode wird natürlich vollständig umgangen von etwas, das git fetch --all ausführt. In diesem Fall müssten Sie entweder dies deaktivieren oder etwas mühsamer tun, wie zum Beispiel

git fetch              # update 'master' from remote
git tag base master    # mark our base point
git rebase -i master   # rewrite some commits
git push --force-with-lease=master:base master:master

Das heißt, erstellen Sie einen base-Tag für Versionen des Upstream-Codes, die Sie gesehen haben und bereit sind zu überschreiben, dann schreiben Sie die Historie neu und pushen Sie schließlich mit Gewalt Änderungen an master, wenn die Remote-Version immer noch bei base ist, unabhängig davon, wie Ihre lokale remotes/origin/master im Hintergrund aktualisiert wurde.

Alternativ wird die Angabe von --force-if-includes als zusätzliche Option zusammen mit --force-with-lease[=<refname>] (d.h. ohne Angabe, auf welchen genauen Commit die Referenz auf der Remote-Seite zeigen muss oder welche Referenzen auf der Remote-Seite geschützt werden) zum Zeitpunkt des "Pushens" überprüft, ob Updates von den Remote-Tracking-Referenzen, die möglicherweise im Hintergrund implizit aktualisiert wurden, lokal integriert wurden, bevor ein erzwungenes Update zugelassen wird.

-f

--force

Normalerweise weigert sich git push, einen Branch zu aktualisieren, der kein Vorfahre des zu pushenden Commits ist.

Diese Flagge deaktiviert diese Prüfung, die anderen Sicherheitsprüfungen in PUSH REGELN unten und die Prüfungen in --force-with-lease. Sie kann dazu führen, dass das Remote-Repository Commits verliert; verwenden Sie sie mit Vorsicht.

Beachten Sie, dass --force für alle gepushten Refs gilt. Daher kann die Verwendung mit push.default auf matching oder mit mehreren konfigurierten Push-Zielen mit remote.*.push andere Refs als den aktuellen Branch überschreiben (einschließlich lokaler Refs, die strikt hinter ihrem Remote-Gegenstück liegen). Um nur einen Branch mit Gewalt zu pushen, verwenden Sie ein + vor dem zu pushenden Refspec (z.B. git push origin +master, um den master-Branch mit Gewalt zu pushen). Siehe den Abschnitt <refspec>... oben für Details.

--force-if-includes

--no-force-if-includes

Erzwingt ein Update nur, wenn die Spitze der Remote-Tracking-Referenz lokal integriert wurde.

Diese Option aktiviert eine Prüfung, die überprüft, ob die Spitze der Remote-Tracking-Referenz von einem der "Reflog"-Einträge des lokalen Branches, auf dem sie basiert, für einen Rewrite erreichbar ist. Die Prüfung stellt sicher, dass alle Updates vom Remote lokal übernommen wurden, indem sie das erzwungene Update ablehnt, wenn dies nicht der Fall ist.

Wenn die Option ohne Angabe von --force-with-lease übergeben wird oder zusammen mit --force-with-lease=<refname>:<expect> angegeben wird, ist es ein "No-Op".

Die Angabe von --no-force-if-includes deaktiviert dieses Verhalten.

--repo=<repository>

Diese Option ist äquivalent zum Argument <repository>. Wenn beide angegeben sind, hat das Argument der Befehlszeile Vorrang.

-u

--set-upstream

Für jeden Branch, der aktuell ist oder erfolgreich gepusht wurde, wird eine Upstream-Referenz (Tracking-Referenz) hinzugefügt, die von einem git-pull[1] ohne Argumente und anderen Befehlen verwendet wird. Weitere Informationen finden Sie unter branch.<name>.merge in git-config[1].

--thin

--no-thin

Diese Optionen werden an git-send-pack[1] übergeben. Eine dünne Übertragung reduziert die Menge der gesendeten Daten erheblich, wenn Sender und Empfänger viele gemeinsame Objekte haben. Der Standard ist --thin.

-q

--quiet

Unterdrückt die gesamte Ausgabe, einschließlich der Liste der aktualisierten Refs, es sei denn, es tritt ein Fehler auf. Der Fortschritt wird nicht auf den Standardfehlerstrom gemeldet.

-v

--verbose

Führen Sie ausführlich aus.

--progress

Der Fortschrittsstatus wird standardmäßig auf dem Standardfehlerausgabestrom berichtet, wenn dieser an ein Terminal angeschlossen ist, es sei denn, -q wird angegeben. Diese Flag erzwingt die Anzeige des Fortschrittsstatus, auch wenn der Standardfehlerausgabestrom nicht an ein Terminal weitergeleitet wird.

--no-recurse-submodules

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

Kann verwendet werden, um sicherzustellen, dass alle Submodul-Commits, die von den zu pushenden Revisionen verwendet werden, auf einem Remote-Tracking-Branch verfügbar sind. Wenn check verwendet wird, prüft Git, ob alle Submodul-Commits, die in den zu pushenden Revisionen geändert wurden, auf mindestens einem Remote des Submoduls verfügbar sind. Wenn Commits fehlen, wird der Push abgebrochen und mit einem Nicht-Null-Status beendet. Wenn on-demand verwendet wird, werden alle Submodule, die in den zu pushenden Revisionen geändert wurden, gepusht. Wenn on-demand nicht alle notwendigen Revisionen pushen konnte, wird es ebenfalls abgebrochen und mit einem Nicht-Null-Status beendet. Wenn only verwendet wird, werden alle Submodule gepusht, während das Superprojekt nicht gepusht wird. Ein Wert von no oder die Verwendung von --no-recurse-submodules kann verwendet werden, um die Konfigurationsvariable push.recurseSubmodules zu überschreiben, wenn keine Submodul-Rekursion erforderlich ist.

Bei Verwendung von on-demand oder only, wenn ein Submodul eine Konfiguration "push.recurseSubmodules={on-demand,only}" oder "submodule.recurse" hat, wird eine weitere Rekursion stattfinden. In diesem Fall wird "only" als "on-demand" behandelt.

--verify

--no-verify

Schaltet den pre-push Hook um (siehe githooks[5]). Der Standard ist --verify, was dem Hook die Möglichkeit gibt, den Push zu verhindern. Mit --no-verify wird der Hook vollständig umgangen.

-4

--ipv4

Nur IPv4-Adressen verwenden, IPv6-Adressen ignorieren.

-6

--ipv6

Nur IPv6-Adressen verwenden, IPv4-Adressen ignorieren.

GIT URLS

Im Allgemeinen enthalten URLs Informationen über das Transportprotokoll, die Adresse des Remote-Servers und den Pfad zum Repository. Abhängig vom Transportprotokoll können einige dieser Informationen fehlen.

Git unterstützt ssh, git, http und https Protokolle (zusätzlich können ftp und ftps zum Abrufen verwendet werden, aber das ist ineffizient und veraltet; verwenden Sie sie nicht).

Der native Transport (d.h. git:// URL) führt keine Authentifizierung durch und sollte mit Vorsicht in ungesicherten Netzwerken verwendet werden.

Die folgenden Syntaxe können damit verwendet werden

ssh://[<user>@]<host>[:<port>]/<pfad-zum-git-repo>
git://<host>[:<port>]/<pfad-zum-git-repo>
http[s]://<host>[:<port>]/<pfad-zum-git-repo>
ftp[s]://<host>[:<port>]/<pfad-zum-git-repo>

Eine alternative scp-ähnliche Syntax kann auch mit dem ssh-Protokoll verwendet werden

[<user>@]<host>:/<pfad-zum-git-repo>

Diese Syntax wird nur erkannt, wenn keine Schrägstriche vor dem ersten Doppelpunkt stehen. Dies hilft, einen lokalen Pfad, der einen Doppelpunkt enthält, zu unterscheiden. Zum Beispiel kann der lokale Pfad foo:bar als absoluter Pfad oder ./foo:bar angegeben werden, um eine Fehlinterpretation als ssh-URL zu vermeiden.

Die Protokolle ssh und git unterstützen zusätzlich die Erweiterung von ~<username>

ssh://[<user>@]<host>[:<port>]/~<user>/<pfad-zum-git-repo>
git://<host>[:<port>]/~<user>/<pfad-zum-git-repo>
[<user>@]<host>:~<user>/<pfad-zum-git-repo>

Für lokale Repositories, die ebenfalls nativ von Git unterstützt werden, können die folgenden Syntaxe verwendet werden

/pfad/zu/repo.git/
file:///pfad/zu/repo.git/

Diese beiden Syntaxe sind weitgehend äquivalent, außer beim Klonen, wenn die erste die Option --local impliziert. Siehe git-clone[1] für Details.

git clone, git fetch und git pull, aber nicht git push, akzeptieren auch eine geeignete Bundle-Datei. Siehe git-bundle[1].

Wenn Git ein bestimmtes Transportprotokoll nicht handhaben kann, versucht es, den Remote-Helfer remote-<transport> zu verwenden, falls einer existiert. Um explizit einen Remote-Helfer anzufordern, kann die folgende Syntax verwendet werden

<transport>::<adresse>

wobei <adresse> ein Pfad, ein Server und Pfad oder eine beliebige URL-ähnliche Zeichenkette sein kann, die vom spezifischen aufgerufenen Remote-Helfer erkannt wird. Siehe gitremote-helpers[7] für Details.

Wenn es eine große Anzahl ähnlich benannter Remote-Repositories gibt und Sie ein anderes Format dafür verwenden möchten (so dass die von Ihnen verwendeten URLs in URLs umgeschrieben werden, die funktionieren), können Sie einen Konfigurationsabschnitt der Form erstellen

	[url "<actual-url-base>"]
		insteadOf = <other-url-base>

Zum Beispiel, mit diesem

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

eine URL wie "work:repo.git" oder "host.xz:/path/to/repo.git" wird in jedem Kontext, der eine URL entgegennimmt, zu "git://git.host.xz/repo.git" umgeschrieben.

Wenn Sie URLs nur für Push-Operationen umschreiben möchten, können Sie einen Konfigurationsabschnitt der Form erstellen

	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>

Zum Beispiel, mit diesem

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

eine URL wie "git://example.org/path/to/repo.git" wird für Push-Operationen zu "ssh://example.org/path/to/repo.git" umgeschrieben, aber Pull-Operationen verwenden weiterhin die ursprüngliche URL.

REMOTES

Der Name eines der folgenden kann anstelle einer URL als Argument repository verwendet werden

ein Remote in der Git-Konfigurationsdatei: $GIT_DIR/config,
eine Datei im Verzeichnis $GIT_DIR/remotes oder
eine Datei im Verzeichnis $GIT_DIR/branches.

All dies erlaubt Ihnen auch, die Refspec von der Kommandozeile wegzulassen, da jede dieser Dateien eine Refspec enthält, die Git standardmäßig verwendet.

Benannter Remote in der Konfigurationsdatei

Sie können den Namen eines Remotes angeben, den Sie zuvor mit git-remote[1], git-config[1] oder durch manuelle Bearbeitung der Datei $GIT_DIR/config konfiguriert haben. Die URL dieses Remotes wird verwendet, um auf das Repository zuzugreifen. Die Refspec dieses Remotes wird standardmäßig verwendet, wenn Sie keine Refspec auf der Kommandozeile angeben. Der Eintrag in der Konfigurationsdatei würde wie folgt aussehen:

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

Die <pushurl> wird nur für Pushes verwendet. Sie ist optional und standardmäßig <URL>. Das Pushen zu einem Remote betrifft alle definierten Push-URLs oder alle definierten URLs, wenn keine Push-URLs definiert sind. Fetch hingegen holt nur von der ersten definierten URL, wenn mehrere URLs definiert sind.

Benannte Datei in `$GIT_DIR/remotes`

Sie können den Namen einer Datei in $GIT_DIR/remotes angeben. Die URL in dieser Datei wird verwendet, um auf das Repository zuzugreifen. Die Refspec in dieser Datei wird als Standard verwendet, wenn Sie keine Refspec auf der Kommandozeile angeben. Diese Datei sollte folgendes Format haben:

	URL: one of the above URL formats
	Push: <refspec>
	Pull: <refspec>

Push: Zeilen werden von git push verwendet und Pull: Zeilen werden von git pull und git fetch verwendet. Mehrere Push: und Pull: Zeilen können für zusätzliche Branch-Mappings angegeben werden.

Benannte Datei in `$GIT_DIR/branches`

Sie können den Namen einer Datei in $GIT_DIR/branches angeben. Die URL in dieser Datei wird verwendet, um auf das Repository zuzugreifen. Diese Datei sollte folgendes Format haben:

	<URL>#<head>

<URL> ist erforderlich; #<head> ist optional.

Abhängig vom Vorgang verwendet Git eine der folgenden Refspecs, wenn Sie keine auf der Kommandozeile angeben. <branch> ist der Name dieser Datei in $GIT_DIR/branches und <head> standardmäßig master.

git fetch verwendet

	refs/heads/<head>:refs/heads/<branch>

git push verwendet

	HEAD:refs/heads/<head>

UPSTREAM BRANCHES

Branches in Git können optional einen Upstream-Remote-Branch haben. Git verwendet standardmäßig den Upstream-Branch für Remote-Operationen, z. B.

Dies ist der Standard für git pull oder git fetch ohne Argumente.
Dies ist der Standard für git push ohne Argumente, mit einigen Ausnahmen. Sie können zum Beispiel die Option branch.<name>.pushRemote verwenden, um zu einem anderen Remote zu pushen, als von dem Sie ziehen, und standardmäßig mit push.default=simple muss der von Ihnen konfigurierte Upstream-Branch denselben Namen haben.
Verschiedene Befehle, einschließlich git checkout und git status, zeigen Ihnen, wie viele Commits zu Ihrem aktuellen Branch und zum Upstream hinzugefügt wurden, seitdem Sie ihn verzweigt haben, z. B. "Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively".

Der Upstream wird in .git/config in den Feldern "remote" und "merge" gespeichert. Wenn zum Beispiel main's Upstream origin/main ist

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

Sie können einen Upstream-Branch explizit mit git push --set-upstream <remote> <branch> festlegen, aber Git legt den Upstream oft automatisch für Sie fest, zum Beispiel

Wenn Sie ein Repository klonen, setzt Git den Upstream für den Standard-Branch automatisch.
Wenn die Konfigurationsoption push.autoSetupRemote gesetzt ist, setzt git push den Upstream automatisch beim ersten Push eines Branches.
Das Auschecken eines Remote-Tracking-Branches mit git checkout <branch> erstellt automatisch einen lokalen Branch mit diesem Namen und setzt den Upstream auf den Remote-Branch.

Hinweis

Upstream-Branches werden manchmal als "Tracking-Informationen" bezeichnet, wie in "set the branch’s tracking information".

AUSGABE

Die Ausgabe von "git push" hängt von der verwendeten Transportmethode ab; dieser Abschnitt beschreibt die Ausgabe beim Pushen über das Git-Protokoll (entweder lokal oder über SSH).

Der Status des Pushes wird in tabellarischer Form ausgegeben, wobei jede Zeile den Status eines einzelnen Refs darstellt. Jede Zeile hat das Format

 <flag> <summary> <from> -> <to> (<reason>)

Wenn --porcelain verwendet wird, hat jede Zeile der Ausgabe das Format

 <flag> \t <from>:<to> \t <summary> (<reason>)

Der Status von "up-to-date" Refs wird nur angezeigt, wenn die Option --porcelain oder --verbose verwendet wird.

flag

Ein einzelnes Zeichen, das den Status des Refs angibt.

(leerzeichen): für einen erfolgreich gepushten Fast-Forward;
+: für ein erfolgreiches erzwungenes Update;
-: für einen erfolgreich gelöschten Ref;
*: für einen erfolgreich neuen Ref;
!: für einen Ref, der abgelehnt oder fehlgeschlagen ist, zu pushen; und
=: für einen Ref, der aktuell war und nicht gepusht werden musste.

summary

Für einen erfolgreich gepushten Ref zeigt die Zusammenfassung die alten und neuen Werte des Refs in einem Format an, das für die Verwendung als Argument für git log geeignet ist (dies ist in den meisten Fällen <old>..<new> und <old>...<new> für erzwungene Nicht-Fast-Forward-Updates).

Für ein fehlgeschlagenes Update werden weitere Details angegeben:

rejected: Git hat nicht versucht, den Ref überhaupt zu senden, typischerweise weil es kein Fast-Forward ist und Sie das Update nicht erzwungen haben.
remote rejected: Das Remote-Ende hat das Update verweigert. Normalerweise verursacht durch einen Hook auf der Remote-Seite oder weil das Remote-Repository eine der folgenden Sicherheitsoptionen aktiviert hat: receive.denyCurrentBranch (für Pushes zum ausgecheckten Branch), receive.denyNonFastForwards (für erzwungene Nicht-Fast-Forward-Updates), receive.denyDeletes oder receive.denyDeleteCurrent. Siehe git-config[1].
remote failure: Das Remote-Ende hat das erfolgreiche Update des Refs nicht gemeldet, möglicherweise aufgrund eines temporären Fehlers auf der Remote-Seite, einer Unterbrechung der Netzwerkverbindung oder eines anderen transienten Fehlers.

from

Der Name des zu pushenden lokalen Refs, abzüglich seines Präfixes refs/<type>/. Im Falle einer Löschung wird der Name des lokalen Refs weggelassen.

to

Der Name des zu aktualisierenden Remote-Refs, abzüglich seines Präfixes refs/<type>/.

reason

Eine für Menschen lesbare Erklärung. Im Falle von erfolgreich gepushten Refs wird keine Erklärung benötigt. Für einen fehlgeschlagenen Ref wird der Grund für das Scheitern beschrieben.

PUSH REGELN

Als Sicherheitsmerkmal erlaubt der Befehl git push nur bestimmte Arten von Updates, um zu verhindern, dass Sie versehentlich Daten im Remote-Repository verlieren.

Da Branches und Tags unterschiedlich verwendet werden sollen, sind die Sicherheitsregeln für das Pushen zu einem Branch anders als die Regeln für das Pushen zu einem Tag. In den folgenden Regeln bedeutet "Update" jede Modifikation außer Löschungen und Erstellungen. Löschungen und Erstellungen sind immer erlaubt, es sei denn, sie sind durch Konfiguration oder Hooks verboten.

Wenn das Push-Ziel ein Branch (refs/heads/*) ist: Nur Fast-Forward-Updates sind erlaubt, was bedeutet, dass das Ziel ein Vorfahre des Quell-Commits sein muss. Die Quelle muss ein Commit sein.
Wenn das Push-Ziel ein Tag (refs/tags/*) ist: Alle Updates werden abgelehnt. Die Quelle kann jedes Objekt sein.
Wenn das Push-Ziel kein Branch oder Tag ist
- Wenn die Quelle ein Baum- oder Blob-Objekt ist, werden alle Updates abgelehnt.
- Wenn die Quelle ein Tag- oder Commit-Objekt ist, sind alle Fast-Forward-Updates erlaubt, auch in Fällen, in denen das, was per Fast-Forward aktualisiert wird, kein Commit ist, sondern ein Tag-Objekt, das zufällig auf einen neuen Commit zeigt, der ein Fast-Forward des Commits des letzten Tags (oder Commits) ist, den es ersetzt. Das Ersetzen eines Tags durch einen völlig anderen Tag ist ebenfalls erlaubt, wenn er auf denselben Commit zeigt, ebenso wie das Pushen eines "gepellten" Tags, d.h. das Pushen des Commits, auf den das vorhandene Tag-Objekt zeigt, oder eines neuen Tag-Objekts, auf das ein vorhandener Commit zeigt.

Sie können diese Regeln überschreiben, indem Sie --force übergeben oder den optionalen führenden + zu einem Refspec hinzufügen. Die einzigen Ausnahmen sind, dass kein erzwungenes Update ein Nicht-Commit-Objekt in einen Branch akzeptieren lässt und dass das Erzwingen nicht dazu führt, dass das Remote-Repository einen Push akzeptiert, den es konfiguriert hat, um ihn zu verweigern.

Hooks und Konfiguration können diese Regeln auch überschreiben oder ergänzen, siehe z.B. receive.denyNonFastForwards und receive.denyDeletes in git-config[1] und pre-receive und update in githooks[5].

HINWEIS ZU FAST-FORWARD UPDATES

Wenn ein Update einen Branch (oder allgemeiner eine Referenz) ändert, der früher auf Commit A zeigte und nun auf einen anderen Commit B zeigt, nennt man dies ein Fast-Forward-Update, wenn und nur wenn B ein Nachfahre von A ist.

Bei einem Fast-Forward-Update von A nach B ist die Menge der Commits, auf denen der ursprüngliche Commit A aufbaute, eine Teilmenge der Commits, auf denen der neue Commit B aufbaut. Daher geht keine Historie verloren.

Im Gegensatz dazu geht bei einem Nicht-Fast-Forward-Update Historie verloren. Angenommen, Sie und jemand anderes haben vom selben Commit X aus begonnen, und Sie haben eine Historie aufgebaut, die zu Commit B führt, während die andere Person eine Historie aufgebaut hat, die zu Commit A führt. Die Historie sieht so aus:

      B
     /
 ---X---A

Angenommen weiter, dass die andere Person bereits die Änderungen, die zu A geführt haben, in das ursprüngliche Repository gepusht hat, von dem Sie beide den ursprünglichen Commit X erhalten haben.

Der Push der anderen Person hat den Branch, der früher auf Commit X zeigte, aktualisiert, um auf Commit A zu zeigen. Dies ist ein Fast-Forward.

Aber wenn Sie versuchen zu pushen, werden Sie versuchen, den Branch (der nun auf A zeigt) mit Commit B zu aktualisieren. Dies ist *kein* Fast-Forward. Wenn Sie dies tun würden, gehen die von Commit A eingeführten Änderungen verloren, da jeder nun von B aus aufbauen wird.

Der Befehl erlaubt standardmäßig kein Update, das kein Fast-Forward ist, um solche Verluste von Historie zu verhindern.

Wenn Sie Ihre Arbeit (Verlauf von X bis B) oder die Arbeit der anderen Person (Verlauf von X bis A) nicht verlieren möchten, müssen Sie zuerst den Verlauf aus dem Repository abrufen, einen Verlauf erstellen, der die Änderungen beider Parteien enthält, und das Ergebnis zurückpushen.

Sie können "git pull" ausführen, potenzielle Konflikte lösen und das Ergebnis zurückpushen ("git push"). Ein "git pull" erstellt einen Merge-Commit C zwischen den Commits A und B.

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

Das Aktualisieren von A mit dem resultierenden Merge-Commit führt zu einem Fast-Forward, und Ihr Push wird akzeptiert.

Alternativ können Sie Ihre Änderung zwischen X und B auf A neu basieren (rebase) mit "git pull --rebase" und das Ergebnis zurückpushen. Der Rebase erstellt einen neuen Commit D, der die Änderung zwischen X und B auf A aufbaut.

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

Auch hier führt das Aktualisieren von A mit diesem Commit zu einem Fast-Forward, und Ihr Push wird akzeptiert.

Es gibt eine weitere häufige Situation, in der Sie eine Nicht-Fast-Forward-Ablehnung erhalten können, wenn Sie versuchen zu pushen, und das ist sogar dann möglich, wenn Sie in ein Repository pushen, in das niemand sonst pusht. Nachdem Sie Commit A selbst gepusht haben (im ersten Bild dieses Abschnitts), ersetzen Sie ihn durch "git commit --amend", um Commit B zu erzeugen, und versuchen Sie, ihn rauszupushen, weil Sie vergessen haben, dass Sie A bereits herausgepusht haben. In einem solchen Fall, und nur wenn Sie sicher sind, dass niemand inzwischen Ihren früheren Commit A abgerufen hat (und darauf aufgebaut hat), können Sie "git push --force" ausführen, um ihn zu überschreiben. Mit anderen Worten, "git push --force" ist eine Methode, die für Fälle reserviert ist, in denen Sie tatsächlich den Verlauf verlieren möchten.

BEISPIELE

git push

Funktioniert wie git push <remote>, wobei <remote> das Remote der aktuellen Branch ist (oder origin, wenn für den aktuellen Branch kein Remote konfiguriert ist).

git push origin

Ohne zusätzliche Konfiguration pusht den aktuellen Branch zum konfigurierten Upstream (branch.<name>.merge Konfigurationsvariable), wenn er denselben Namen wie der aktuelle Branch hat, und gibt andernfalls eine Fehlermeldung aus, ohne zu pushen.

Das Standardverhalten dieses Befehls, wenn keine <refspec> angegeben ist, kann durch Setzen der push Option des Remotes oder der push.default Konfigurationsvariable konfiguriert werden.

Um beispielsweise standardmäßig nur den aktuellen Branch nach origin zu pushen, verwenden Sie git config remote.origin.push HEAD. Jede gültige <refspec> (wie die in den folgenden Beispielen) kann als Standard für git push origin konfiguriert werden.

git push origin :

Pusht "matching" Branches nach origin. Siehe <refspec> im Abschnitt OPTIONEN oben für eine Beschreibung von "matching" Branches.

git push origin master

Sucht nach einem Ref, der master im Quell-Repository entspricht (höchstwahrscheinlich findet er refs/heads/master) und aktualisiert denselben Ref (z. B. refs/heads/master) im origin Repository damit. Wenn master remote nicht existiert hätte, würde er erstellt werden.

git push origin HEAD

Eine praktische Möglichkeit, den aktuellen Branch unter demselben Namen zum Remote zu pushen.

git push mothership master:satellite/master dev:satellite/dev

Verwendet den Quell-Ref, der mit master übereinstimmt (z. B. refs/heads/master), um den Ref zu aktualisieren, der mit satellite/master übereinstimmt (höchstwahrscheinlich refs/remotes/satellite/master) im mothership Repository; tut dasselbe für dev und satellite/dev.

Siehe den Abschnitt, der <refspec>... oben beschreibt, für eine Diskussion der Matching-Semantik.

Dies dient dazu, git fetch auf dem mothership zu emulieren, indem git push in umgekehrter Richtung verwendet wird, um die auf satellite durchgeführte Arbeit zu integrieren. Dies ist oft notwendig, wenn Sie nur in einer Richtung eine Verbindung herstellen können (d. h. Satellite kann sich mit Mothership verbinden, aber Mothership kann keine Verbindung zu Satellite initiieren, da letzteres hinter einer Firewall liegt oder keinen sshd ausführt).

Nachdem Sie dieses git push auf der satellite Maschine ausgeführt haben, würden Sie sich bei der mothership anmelden und dort git merge ausführen, um die Emulation von git pull abzuschließen, das auf mothership ausgeführt worden wäre, um Änderungen zu pullen, die auf satellite vorgenommen wurden.

git push origin HEAD:master

Pusht den aktuellen Branch zum Remote-Ref, der master im origin Repository entspricht. Diese Form ist praktisch, um den aktuellen Branch zu pushen, ohne seinen lokalen Namen zu kennen.

git push origin master:refs/heads/experimental

Erstellt den Branch experimental im origin Repository, indem der aktuelle master Branch kopiert wird. Diese Form ist nur erforderlich, um einen neuen Branch oder Tag im Remote-Repository zu erstellen, wenn der lokale und der Remote-Name unterschiedlich sind. Andernfalls funktioniert der Ref-Name allein.

git push origin :experimental

Sucht nach einem Ref, der experimental im origin Repository entspricht (z. B. refs/heads/experimental), und löscht ihn.

git push origin +dev:master

Aktualisiert den master-Branch des origin-Repositories mit dem dev-Branch, was Nicht-Fast-Forward-Updates zulässt. **Dies kann dazu führen, dass nicht referenzierte Commits im origin-Repository hängen bleiben.** Betrachten Sie die folgende Situation, in der ein Fast-Forward nicht möglich ist

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

Der obige Befehl würde das origin-Repository ändern zu

		      A---B  (unnamed branch)
		     /
	    o---o---o---X---Y---Z  master

Commits A und B würden nicht mehr zu einem Branch mit einem symbolischen Namen gehören und wären somit unerreichbar. Daher würden diese Commits durch einen git gc Befehl auf dem origin-Repository entfernt werden.

SICHERHEIT

Die Fetch- und Push-Protokolle sind nicht darauf ausgelegt, zu verhindern, dass eine Seite Daten von einem anderen Repository stiehlt, die nicht zum Teilen bestimmt waren. Wenn Sie private Daten haben, die Sie vor einem böswilligen Peer schützen müssen, ist Ihre beste Option, sie in einem anderen Repository zu speichern. Dies gilt sowohl für Clients als auch für Server. Insbesondere Namensräume auf einem Server sind für die Lesezugriffskontrolle nicht effektiv; Sie sollten einem Namensraum nur Lesezugriff gewähren, wenn Sie einem Client vertrauen würden, der Lesezugriff auf das gesamte Repository hat.

Die bekannten Angriffsvektoren sind wie folgt:

Das Opfer sendet "have"-Zeilen, die die IDs von Objekten ankündigen, die es besitzt und die nicht explizit zum Teilen bestimmt sind, aber zur Optimierung der Übertragung verwendet werden können, wenn der Peer sie ebenfalls hat. Der Angreifer wählt ein Objekt-ID X zum Stehlen aus und sendet eine Ref auf X, muss aber nicht den Inhalt von X senden, da das Opfer es bereits hat. Nun glaubt das Opfer, dass der Angreifer X hat, und es sendet den Inhalt von X später zurück an den Angreifer. (Dieser Angriff ist für einen Client am einfachsten auf einen Server durchzuführen, indem eine Ref auf X in dem Namensraum erstellt wird, auf den der Client Zugriff hat, und diese dann geholt wird. Der wahrscheinlichste Weg für einen Server, dies auf einem Client durchzuführen, ist, X in einen öffentlichen Branch zu "mergen" und zu hoffen, dass der Benutzer zusätzliche Arbeit an diesem Branch leistet und ihn an den Server zurückpusht, ohne den Merge zu bemerken.)
Wie in #1 wählt der Angreifer eine Objekt-ID X zum Stehlen aus. Das Opfer sendet ein Objekt Y, das der Angreifer bereits hat, und der Angreifer behauptet fälschlicherweise, X und nicht Y zu haben, so dass das Opfer Y als Delta gegen X sendet. Das Delta enthüllt dem Angreifer Regionen von X, die Y ähnlich sind.

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

push.autoSetupRemote

Wenn auf "true" gesetzt, wird bei einem Standard-Push, wenn kein Upstream-Tracking für den aktuellen Branch vorhanden ist, --set-upstream angenommen. Diese Option wirkt sich auf die push.default-Optionen simple, upstream und current aus. Sie ist nützlich, wenn neue Branches standardmäßig zum Standard-Remote gepusht werden sollen (wie das Verhalten von push.default=current) und Sie auch das Upstream-Tracking einstellen möchten. Workflows, die am wahrscheinlichsten von dieser Option profitieren, sind simple zentrale Workflows, bei denen erwartet wird, dass alle Branches denselben Namen auf dem Remote haben.

push.default

Definiert die Aktion, die git push ausführen soll, wenn keine Refspec angegeben ist (sei es von der Kommandozeile, der Konfiguration oder anderswo). Verschiedene Werte eignen sich gut für bestimmte Workflows; zum Beispiel ist im rein zentralen Workflow (d. h. die Fetch-Quelle ist gleich dem Push-Ziel) upstream wahrscheinlich das, was Sie wollen. Mögliche Werte sind

nothing - Pusht nichts (Fehlermeldung), es sei denn, eine Refspec wird angegeben. Dies ist hauptsächlich für Leute gedacht, die Fehler vermeiden wollen, indem sie immer explizit sind.
current - Pusht den aktuellen Branch, um einen Branch mit demselben Namen auf der Empfängerseite zu aktualisieren. Funktioniert sowohl in zentralen als auch in nicht-zentralen Workflows.
upstream - Pusht den aktuellen Branch zurück zu dem Branch, dessen Änderungen normalerweise in den aktuellen Branch integriert werden (dieser wird als @{upstream} bezeichnet). Dieser Modus ist nur sinnvoll, wenn Sie in dasselbe Repository pushen, von dem Sie normalerweise pullen (d. h. zentraler Workflow).
tracking - Dies ist ein veraltetes Synonym für upstream.
simple - Pusht den aktuellen Branch mit demselben Namen auf dem Remote.

Wenn Sie in einem zentralisierten Workflow arbeiten (Pushen in dasselbe Repository, von dem Sie pullen, was normalerweise origin ist), müssen Sie einen Upstream-Branch mit demselben Namen konfigurieren.

Dieser Modus ist seit Git 2.0 der Standard und die sicherste Option für Anfänger.
matching - Pusht alle Branches, die auf beiden Seiten denselben Namen haben. Dies bewirkt, dass sich das Repository, in das Sie pushen, den Satz von Branches merkt, die herausgepusht werden (z. B. wenn Sie immer maint und master dorthin pushen und keine anderen Branches, hat das Repository, in das Sie pushen, diese beiden Branches, und Ihre lokalen maint und master werden dorthin gepusht).

Um diesen Modus effektiv zu nutzen, müssen Sie sicherstellen, dass *alle* Branches, die Sie herauspushen, bereit zum Pushen sind, bevor Sie git push ausführen, da der gesamte Sinn dieses Modus darin besteht, Ihnen zu ermöglichen, alle Branches auf einmal zu pushen. Wenn Sie normalerweise die Arbeit an nur einem Branch beenden und das Ergebnis pushen, während andere Branches unfertig sind, ist dieser Modus nichts für Sie. Auch ist dieser Modus nicht geeignet, um in ein gemeinsames zentrales Repository zu pushen, da andere Personen dort neue Branches hinzufügen oder die Spitze bestehender Branches außerhalb Ihrer Kontrolle aktualisieren können.

Dies war früher der Standard, aber nicht mehr seit Git 2.0 (simple ist der neue Standard).

push.followTags

Wenn auf true gesetzt, wird die Option --follow-tags standardmäßig aktiviert. Sie können diese Konfiguration zum Zeitpunkt des Pushes überschreiben, indem Sie --no-follow-tags angeben.

push.gpgSign

Kann auf einen booleschen Wert oder die Zeichenkette if-asked gesetzt werden. Ein wahrer Wert bewirkt, dass alle Pushes GPG-signiert werden, als ob --signed an git-push[1] übergeben würde. Die Zeichenkette if-asked bewirkt, dass Pushes signiert werden, wenn der Server dies unterstützt, als ob --signed=if-asked an git push übergeben würde. Ein falscher Wert kann einen Wert aus einer Konfigurationsdatei mit niedrigerer Priorität überschreiben. Ein explizites Kommandozeilenflag überschreibt diese Konfigurationsoption immer.

push.pushOption

Wenn kein --push-option=<option> Argument von der Kommandozeile gegeben wird, verhält sich git push so, als ob jeder <value> dieser Variablen als --push-option=<value> übergeben würde.

Dies ist eine mehrwertige Variable, und ein leerer Wert kann in einer Konfigurationsdatei mit höherer Priorität (z. B. .git/config in einem Repository) verwendet werden, um Werte zu löschen, die aus Konfigurationsdateien mit niedrigerer Priorität (z. B. $HOME/.gitconfig) geerbt wurden.

Example:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

This will result in only b (a and c are cleared).

push.recurseSubmodules

Kann "check", "on-demand", "only" oder "no" sein, mit demselben Verhalten wie "push --recurse-submodules". Wenn nicht gesetzt, wird standardmäßig no verwendet, es sei denn, submodule.recurse ist gesetzt (in diesem Fall bedeutet ein true Wert on-demand).

push.useForceIfIncludes

Wenn auf "true" gesetzt, ist dies äquivalent zur Angabe von --force-if-includes als Option für git-push[1] in der Kommandozeile. Das Hinzufügen von --no-force-if-includes zum Zeitpunkt des Pushes überschreibt diese Konfigurationseinstellung.

push.negotiate

Wenn auf "true" gesetzt, wird versucht, die Größe des gesendeten Packfiles durch Verhandlungsrunden zu reduzieren, in denen Client und Server versuchen, gemeinsame Commits zu finden. Wenn "false", verlässt sich Git ausschließlich auf die Ref-Anzeige des Servers, um gemeinsame Commits zu finden.

push.useBitmaps

Wenn auf "false" gesetzt, wird die Verwendung von Bitmaps für "git push" deaktiviert, auch wenn pack.useBitmaps auf "true" gesetzt ist, ohne andere Git-Operationen an der Verwendung von Bitmaps zu hindern. Standard ist true.

Teil der git[1] Suite

Einrichtung und Konfiguration

Projekte holen und erstellen

Grundlegende Snapshots

Branching und Merging

Projekte teilen und aktualisieren

Inspektion und Vergleich

Patching

Debugging

E-Mail

Externe Systeme

Server-Administration

Anleitungen

Administration

Plumbing-Befehle