git-push - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-push - Aktualisieren Sie Remote-Refs zusammen mit den zugehörigen Objekten

ZUSAMMENFASSUNG

git drücken [--alle | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack= ]
[--repo= ] [-f | --force] [--prune] [-v | --verbose]
[-u | --setupstream]
[--[no-]signed|--sign=(true|false|if-asked)]
[--force-with-lease[= [: ]]]
[--nicht verifizieren] [ [ ...]]

BESCHREIBUNG

Aktualisiert Remote-Refs unter Verwendung lokaler Refs, während Objekte gesendet werden, die zum Abschließen der . erforderlich sind
gegebene Refs.

Sie können jedes Mal, wenn Sie hineinschieben, interessante Dinge mit einem Repository passieren, indem Sie
Einrichten Haken dort. Siehe Dokumentation für Git-Receive-Pack(1).

Wenn die Befehlszeile nicht angibt, wohin mit dem gedrückt werden soll Streit,
branch.*.remote-Konfiguration für den aktuellen Branch wird herangezogen, um zu bestimmen, wo
drücken. Wenn die Konfiguration fehlt, wird standardmäßig Herkunft.

Wenn die Befehlszeile nicht angibt, womit gedrückt werden soll ... Argumente oder --alle,
--mirror, --tags Optionen, der Befehl findet den Standard durch Beratung
remote.*.push-Konfiguration, und wenn sie nicht gefunden wird, wird die push.default-Konfiguration auf
entscheiden, was Sie pushen (Siehe git-config(1) für die Bedeutung von push.default).

Wenn weder die Befehlszeile noch die Konfiguration angeben, was gepusht werden soll, ist die Standardeinstellung
Es wird das Verhalten verwendet, das dem einfachen Wert für push entspricht.default: the current
Zweig wird auf den entsprechenden vorgeschalteten Zweig geschoben, aber als Sicherheitsmaßnahme wird der Push
wird abgebrochen, wenn der Upstream-Zweig nicht den gleichen Namen wie der lokale hat.

OPTIONAL

Das "Remote"-Repository, das das Ziel eines Push-Vorgangs ist. Dieser Parameter kann sein
entweder eine URL (siehe Abschnitt GIT-URLs unten) oder der Name einer Fernbedienung (siehe Abschnitt
FERNBEDIENUNGEN unten).

...
Geben Sie an, welche Zielreferenz mit welchem ​​Quellobjekt aktualisiert werden soll. Das Format von a
Parameter ist ein optionales Pluszeichen +, gefolgt vom Quellobjekt ,
gefolgt von einem Doppelpunkt :, gefolgt von der Zielreferenz .

Die ist oft der Name des Zweigs, den Sie pushen möchten, aber es kann jeder sein
beliebiger "SHA-1-Ausdruck", wie master~4 oder HEAD (siehe gitrevisionen(7)).

Die teilt mit, welche Referenz auf der Remote-Seite mit diesem Push aktualisiert wird. Willkürlich
Ausdrücke können hier nicht verwendet werden, es muss eine tatsächliche Referenz angegeben werden. Wenn git push
[ ] ohne irgendetwas Argument ist so eingestellt, dass einige Referenzen am aktualisiert werden
Ziel mit mit Fernbedienung. .push-Konfigurationsvariable, :
Teil kann weggelassen werden – ein solcher Push aktualisiert eine Referenz, die normalerweise aktualisiert ohne
irgendein auf der Kommandozeile. Ansonsten fehlt: bedeutet, dasselbe zu aktualisieren
ref als die .

Das von referenzierte Objekt wird verwendet, um die . zu aktualisieren Referenz auf der Fernbedienung
Seite. Standardmäßig ist dies nur erlaubt, wenn ist kein Tag (annotiert oder
leicht) und dann nur, wenn es schnell vorspulen kann . Durch das optionale
führendes +, können Sie Git anweisen, das zu aktualisieren ref, auch wenn es nicht erlaubt ist von
Standard (z. B. kein schneller Vorlauf.) Dies funktioniert nicht versuch zu fusionieren hinein
. Siehe BEISPIELE unten für Details.

Schild bedeutet dasselbe wie refs/tags/ :refs/tags/ .

Ein leeres schieben ermöglicht Ihnen das Löschen ref aus dem Remote-Repository.

Die spezielle refspec : (oder +: um Updates ohne Fast-Forward zu ermöglichen) weist Git an zu pushen
"passende" Branches: für jeden Branch, der auf der lokalen Seite existiert, die Remote-Seite
wird aktualisiert, wenn auf der Gegenseite bereits ein gleichnamiger Zweig existiert.

--alle
Push alle Branches (zB refs unter refs/heads/); kann nicht mit anderen verwendet werden .

--Pflaume
Entfernen Sie entfernte Zweige, die kein lokales Gegenstück haben. Zum Beispiel eine Fernbedienung
Branch tmp wird entfernt, wenn kein lokaler Branch mit demselben Namen existiert
mehr. Dies respektiert auch Refspecs, zB git push --prune remote
refs/heads/*:refs/tmp/* würde sicherstellen, dass entfernte refs/tmp/foo entfernt werden, wenn
refs/heads/foo existiert nicht.

--Spiegel
Anstatt jede Ref zu pushen zu benennen, legt sie fest, dass alle Refs unter refs/ (was
beinhaltet, ist aber nicht beschränkt auf refs/heads/, refs/remotes/ und refs/tags/) gespiegelt werden
zum Remote-Repository. Neu erstellte lokale Refs werden an das entfernte Ende gepusht,
lokal aktualisierte Refs werden am entfernten Ende erzwungen aktualisiert und gelöschte Refs werden aktualisiert
vom entfernten Ende entfernt. Dies ist die Standardeinstellung, wenn die Konfigurationsoption
Fernbedienung. .Spiegel ist eingestellt.

-n, --Trockenlauf
Tun Sie alles, außer die Updates tatsächlich zu senden.

--Porzellan
Erstellen Sie eine maschinenlesbare Ausgabe. Die Ausgabestatuszeile für jede Referenz ist
tabulatorgetrennt und an stdout statt an stderr gesendet. Die vollständigen symbolischen Namen der
refs werden gegeben.

--löschen
Alle aufgelisteten Refs werden aus dem Remote-Repository gelöscht. Dies ist das gleiche wie das Präfixieren
alle refs mit einem Doppelpunkt.

--Stichworte
Alle Refs unter Refs/Tags werden gepusht, zusätzlich zu den Refspecs, die explizit auf der Seite aufgeführt sind
Befehlszeile.

--follow-tags
Pushen Sie alle Refs, die ohne diese Option gepusht würden, und pushen Sie auch kommentierte
Tags in Refs/Tags, die in der Fernbedienung fehlen, aber auf Commit-ish zeigen, dass
sind von den gepushten Refs erreichbar. Dies kann auch mit angegeben werden
Konfigurationsvariable push.followTags. Weitere Informationen finden Sie unter push.followTags in
git-config(1).

--[no-]signed, --sign=(true|false|if-asked)
GPG-signieren Sie die Push-Anfrage, um die Refs auf der empfangenden Seite zu aktualisieren, damit dies möglich ist
von den Haken überprüft und/oder protokolliert werden. Bei false oder --no-signed wird nicht signiert
versucht. Bei true oder --signed schlägt der Push fehl, wenn der Server nicht unterstützt
signierte Pushs. Wenn auf if-asked gesetzt, signieren, wenn und nur wenn der Server signiert unterstützt
schiebt. Der Push schlägt auch fehl, wenn der eigentliche Aufruf von gpg --sign fehlschlägt. Sehen Git-
Empfangspaket(1) für die Details auf der Empfängerseite.

--[no-]atomar
Verwenden Sie eine atomare Transaktion auf der Remote-Seite, falls verfügbar. Entweder alle Refs sind
aktualisiert, oder bei einem Fehler werden keine Referenzen aktualisiert. Wenn der Server Atomic nicht unterstützt
schiebt der Schub wird fehlschlagen.

--receive-pack= , --exec=
Weg zum Git-Receive-Pack Programm am entfernten Ende. Manchmal nützlich beim Schieben
zu einem Remote-Repository über ssh, und Sie haben das Programm nicht in einem Verzeichnis auf dem
Standardwert $PFAD.

--[no-]force-with-lease, --force-with-lease= ,
--force-with-lease= :
Normalerweise weigert sich "git push" eine Remote-Ref zu aktualisieren, die kein Vorfahre des ist
local ref verwendet, um es zu überschreiben.

Diese Option überschreibt diese Einschränkung, wenn der aktuelle Wert der Remote-Ref der
erwarteter Wert. "git push" schlägt sonst fehl.

Stellen Sie sich vor, Sie müssen das, was Sie bereits veröffentlicht haben, rebasieren. Sie müssen
Umgehe die "Muss Fast-Forward"-Regel, um den ursprünglichen Verlauf zu ersetzen
mit der umbasierten Geschichte veröffentlicht. Wenn jemand anderes auf Ihrem Original aufgebaut hat
Verlauf während Sie rebasieren, kann die Zweigspitze an der Fernbedienung mit fortschreiten
ihr Commitment und blindes Drängen mit --force wird ihre Arbeit verlieren.

Mit dieser Option können Sie sagen, dass Sie erwarten, dass der Verlauf, den Sie aktualisieren, das ist, was Sie
umgebaut und ersetzen wollen. Wenn die Remote-Ref immer noch auf den Commit verweist, den Sie
angegeben, können Sie sicher sein, dass keine anderen Personen etwas an der ref. Es ist wie
einen "Lease" für den Ref nehmen, ohne ihn explizit zu sperren, und der Remote-Ref ist
nur aktualisiert, wenn der "Lease" noch gültig ist.

--force-with-lease allein, ohne die Details anzugeben, schützt alle Remote-Refs
die aktualisiert werden sollen, indem ihr aktueller Wert gleich dem
Remote-Tracking-Zweig haben wir für sie.

--force-with-lease= , ohne den erwarteten Wert anzugeben, schützt die
namens ref (allein), wenn es aktualisiert werden soll, indem sein aktueller Wert
das gleiche wie der Remote-Tracking-Zweig, den wir dafür haben.

--force-with-lease= : schützt die benannte ref (allein), wenn dies der Fall ist
aktualisiert werden, indem sein aktueller Wert mit dem angegebenen übereinstimmen muss
Wert (was sich von dem Remote-Tracking-Zweig unterscheiden darf)
für den Refnamen haben, oder wir müssen nicht einmal einen solchen Remote-Tracking-Zweig haben
wenn dieses Formular verwendet wird).

Beachten Sie, dass alle Formen außer --force-with-lease= : das spezifiziert
die erwarteten Stromwerte der ref sind explizit noch experimentell und ihre
Semantik kann sich ändern, wenn wir Erfahrungen mit dieser Funktion sammeln.

"--no-force-with-lease" bricht alle vorherigen --force-with-lease auf dem Befehl ab
Linie.

-f, --force
Normalerweise weigert sich der Befehl, eine Remote-Ref zu aktualisieren, die kein Vorfahre des ist
local ref verwendet, um es zu überschreiben. Auch wenn die Option --force-with-lease verwendet wird,
Der Befehl weigert sich, eine Remote-Ref zu aktualisieren, deren aktueller Wert nicht mit dem übereinstimmt
erwartet.

Dieses Flag deaktiviert diese Prüfungen und kann dazu führen, dass das Remote-Repository Commits verliert;
verwenden Sie es mit Vorsicht.

Beachten Sie, dass --force für alle Refs gilt, die gepusht werden, daher wird es mit verwendet
push.default auf übereinstimmend eingestellt oder mit mehreren Push-Zielen konfiguriert mit
remote.*.push kann andere Refs als den aktuellen Branch überschreiben (einschließlich lokaler Refs
die strikt hinter ihrem entfernten Gegenstück stehen). Um einen Push auf nur einen zu erzwingen
Branch, verwenden Sie ein + vor der Refspec, um zu pushen (zB git push origin +master to force
ein Push zum Master-Zweig). Siehe die ... Abschnitt oben für Details.

--repo=
Diese Option entspricht der Streit. Wenn beide angegeben sind, wird die
Befehlszeilenargument hat Vorrang.

-u, --set-upstream
Fügen Sie für jeden aktuellen oder erfolgreich gepushten Branch Upstream hinzu (Tracking).
Referenz, verwendet von argument-less git-ziehen(1) und andere Befehle. Für mehr Informationen,
sehen Zweig. .verschmelzen in git-config(1).

--[nichts
Diese Optionen werden weitergegeben an git-send-pack(1). Ein dünner Transfer reduziert deutlich
die Menge der gesendeten Daten, wenn Sender und Empfänger viele der gleichen Objekte teilen
gemeinsames. Der Standardwert ist --dünn.

-q, --leise
Unterdrücken Sie die gesamte Ausgabe, einschließlich der Auflistung aktualisierter Referenzen, es sei denn, es tritt ein Fehler auf.
Der Fortschritt wird nicht an den Standardfehlerstrom gemeldet.

-v, --verbose
Führen Sie ausführlich aus.

--Fortschritt
Der Fortschrittsstatus wird standardmäßig im Standardfehlerstrom gemeldet, wenn er ist
an ein Terminal angehängt, es sei denn, -q ist angegeben. Dieses Flag erzwingt den Fortschrittsstatus sogar
wenn der Standardfehlerstrom nicht an ein Terminal geleitet wird.

--no-recurse-submodules, --recurse-submodules=check|on-demand|no
Kann verwendet werden, um sicherzustellen, dass alle Submodul-Commits, die von den zu verschiebenden Revisionen verwendet werden,
in einem Remote-Tracking-Zweig verfügbar. Wenn aus der Ferne überprüfen verwendet wird Git wird überprüfen, ob alle
Submodul-Commits, die sich in den zu verschiebenden Revisionen geändert haben, sind auf mindestens verfügbar
eine Fernbedienung des Submoduls. Wenn irgendwelche Commits fehlen, wird der Push abgebrochen und
Beenden Sie mit einem Status ungleich Null. Wenn On-Demand werden alle Submodule verwendet, die sich in der . geändert haben
Überarbeitungen, die gepusht werden sollen, werden gepusht. Wenn On-Demand nicht in der Lage war, alles Notwendige zu pushen
Revisionen wird es auch abgebrochen und mit einem Status ungleich Null beendet. Ein Wert von nicht or
mit automatisierten --no-recurse-submodules kann verwendet werden, um die push.recurseSubmodules zu überschreiben
Konfigurationsvariable, wenn keine Submodulrekursion erforderlich ist.

--[no-]überprüfen
Schalten Sie den Vorschubhaken um (siehe Githooks(5)). Die Vorgabe ist --verify, was dem Hook a
Chance, den Stoß zu verhindern. Mit --no-verify wird der Hook komplett umgangen.

GIT URLs

Im Allgemeinen enthalten URLs Informationen über das Transportprotokoll, die Adresse des
Remote-Server und den Pfad zum Repository. Je nach Transportprotokoll können einige
dieser Informationen können fehlen.

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

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

Die folgenden Syntaxen können mit ihnen verwendet werden:

· ssh://[user@]host.xz[:port]/path/to/repo.git/

· git://host.xz[:port]/path/to/repo.git/

· http[s]://host.xz[:port]/path/to/repo.git/

· ftp[s]://host.xz[:port]/path/to/repo.git/

· rsync://host.xz/path/to/repo.git/

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

· [user@]host.xz:Pfad/zu/repo.git/

Diese Syntax wird nur erkannt, wenn vor dem ersten Doppelpunkt keine Schrägstriche stehen. Das hilft
einen lokalen Pfad unterscheiden, der einen Doppelpunkt enthält. Zum Beispiel könnte 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 des ~Benutzernamens:

· ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

· git://host.xz[:port]/~[user]/path/to/repo.git/

· [user@]host.xz:/~[user]/path/to/repo.git/

Für lokale Repositorys, die auch von Git nativ unterstützt werden, können die folgenden Syntaxen sein:
benutzt:

· /Pfad/zu/repo.git/

· file:///path/to/repo.git/

Diese beiden Syntaxen sind größtenteils äquivalent, außer beim Klonen, wenn ersteres impliziert
--lokale Option. Sehen Git-Klon(1) für Details.

Wenn Git nicht weiß, wie ein bestimmtes Transportprotokoll zu handhaben ist, versucht es, das
Fernbedienung- Remote-Helfer, falls vorhanden. Um einen Remote-Helfer explizit anzufordern,
die folgende Syntax kann verwendet werden:

· ::

wo kann ein Pfad, ein Server und ein Pfad oder eine beliebige URL-ähnliche Zeichenfolge sein
wird von dem jeweiligen aufgerufenen Remote-Helper erkannt. Sehen gitremote-Helfer(1) für
Details.

Wenn es eine große Anzahl ähnlich benannter Remote-Repositorys gibt und Sie a
ein anderes Format für sie (so dass die von Ihnen verwendeten URLs in URLs umgeschrieben werden, die
Arbeit), können Sie einen Konfigurationsabschnitt des Formulars erstellen:

[URL" "]
stattOf =

Zum Beispiel damit:

[url "git://git.host.xz/"]
anstattOf = host.xz:/Pfad/zu/
anstattOf = Arbeit:

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

Wenn Sie URLs nur für Push umschreiben möchten, können Sie einen Konfigurationsabschnitt der
bilden:

[URL" "]
pushStattOf =

Zum Beispiel damit:

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

eine URL wie "git://example.org/path/to/repo.git" wird umgeschrieben in
"ssh://example.org/path/to/repo.git" für Pushs, Pulls verwenden jedoch weiterhin das Original
URL.

FERNBEDIENUNGEN

Der Name eines der folgenden kann anstelle einer URL verwendet werden als Streit:

· eine Fernbedienung in der Git-Konfigurationsdatei: $GIT_DIR/config,

· eine Datei im Verzeichnis $GIT_DIR/remotes, oder

· eine Datei im Verzeichnis $GIT_DIR/branches.

All dies ermöglicht es Ihnen auch, die Refspec von der Befehlszeile wegzulassen, da sie jeweils
enthalten eine refspec, die git standardmäßig verwendet.

Namens entfernt in Konfiguration Datei
Sie können den Namen einer Fernbedienung angeben, die Sie zuvor mit . konfiguriert haben
Git-Remote(1) git-config(1) oder sogar durch eine manuelle Bearbeitung der Datei $GIT_DIR/config. Die URL
dieser Fernbedienung wird für den Zugriff auf das Repository verwendet. Die Refspec dieser Fernbedienung ist
Wird standardmäßig verwendet, wenn Sie keine Refspec in der Befehlszeile angeben. Der Eintrag im
config-Datei würde so aussehen:

[Fernbedienung " "]
URL =
pushurl =
drücken =
holen =

Die wird nur für Pushs verwendet. Es ist optional und standardmäßig auf .

Namens 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 in der Befehlszeile keine Refspec angeben. Diese Datei sollte folgendes haben
Format:

URL: eines der oben genannten URL-Formate
Drücken:
Ziehen:

Push: Leitungen werden verwendet von git drücken und Pull: Leitungen werden verwendet von git ziehen und git holen.
Für zusätzliche Zweigzuordnungen können mehrere Push:- und Pull:-Leitungen angegeben werden.

Namens Datei in $GIT_DIR/Filialen
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:

#

erforderlich; # es ist optional.

Abhängig von der Operation verwendet git eine der folgenden Refspecs, wenn Sie dies nicht tun
Geben Sie einen in der Befehlszeile ein. ist der Name dieser Datei in $GIT_DIR/branches
und standardmäßig auf master.

git fetch verwendet:

Refs/Köpfe/ :refs/heads/

git push verwendet:

KOPF: Refs/Köpfe/

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 Pushs wird tabellarisch ausgegeben, wobei jede Zeile den Status repräsentiert
einer einzigen ref. Jede Zeile hat die Form:

-> ( )

Wenn --porcelain verwendet wird, hat jede Zeile der Ausgabe die Form:

\T : \T ( )

Der Status aktueller Referenzen wird nur angezeigt, wenn die Option --porcelain oder --verbose verwendet wird.

Flagge
Ein einzelnes Zeichen, das den Status der Referenz angibt:

(Raum)
für einen erfolgreich gepushten Schnellvorlauf;

+
für ein erfolgreiches erzwungenes Update;

-
für eine erfolgreich gelöschte Referenz;

*
für einen erfolgreich gepushten neuen Ref;

!
für einen Schiedsrichter, der abgelehnt wurde oder nicht pushen konnte; und

=
für einen Schiedsrichter, der auf dem neuesten Stand war und nicht gedrängt werden musste.

Zusammenfassung
Bei einer erfolgreich gepushten Ref zeigt die Zusammenfassung die alten und neuen Werte der Ref in
ein Formular, das als Argument für git log geeignet ist (dies ist .. in den meisten
Fälle und ... für erzwungene Nicht-Fast-Forward-Updates).

Für ein fehlgeschlagenes Update werden weitere Details angegeben:

abgelehnt
Git hat überhaupt nicht versucht, die Referenz zu senden, normalerweise weil es kein schneller Vorlauf ist
und Sie haben das Update nicht erzwungen.

Fernbedienung abgelehnt
Die Gegenstelle hat das Update abgelehnt. Normalerweise verursacht durch einen Haken auf der entfernten Seite, oder
weil für das Remote-Repository eine der folgenden Sicherheitsoptionen gilt:
receive.denyCurrentBranch (für Pushs an den ausgecheckten Branch),
receive.denyNonFastForwards (für erzwungene Nicht-Fast-Forward-Updates),
receive.denyDeletes oder receive.denyDeleteCurrent. Sehen git-config(1).

Fernausfall
Die Gegenstelle hat das erfolgreiche Update der Referenz nicht gemeldet, vielleicht wegen
ein vorübergehender Fehler auf der Gegenseite, eine Unterbrechung der Netzwerkverbindung oder andere
vorübergehender Fehler.

von
Der Name der lokalen Ref, die gepusht wird, abzüglich seiner Refs/ / Präfix. Im Falle des
Beim Löschen wird der Name der lokalen Referenz weggelassen.

zu
Der Name der entfernten Referenz, die aktualisiert wird, abzüglich ihrer Referenzen/ / Präfix.

Grund
Eine menschenlesbare Erklärung. Bei erfolgreich gepushten Refs keine Erklärung
wird gebraucht. Für eine fehlgeschlagene Referenz wird der Grund für den Fehler beschrieben.

HINWEIS ÜBER UNS SCHNELLER VORWÄRTS

Wenn ein Update einen Branch (oder allgemeiner eine Ref) ändert, der früher auf Commit A zeigte
um auf einen anderen Commit B zu zeigen, wird es ein Fast-Forward-Update genannt, wenn und nur wenn B a . ist
Nachkomme von A.

In einem Fast-Forward-Update von A nach B, die Menge der Commits, die das ursprüngliche Commit A erstellt hat
on top of ist eine Teilmenge der Commits, auf denen der neue Commit B aufbaut. Daher ist es nicht
jede Geschichte verlieren.

Im Gegensatz dazu verliert ein Nicht-Fast-Forward-Update den Verlauf. Angenommen, Sie und
jemand anderes hat mit demselben Commit X begonnen, und Sie haben eine Historie erstellt, die zu Commit B führt
während die andere Person eine Historie erstellt hat, die zu Commit A führt. Die Historie sieht so aus:

B
/
---X---A

Nehmen Sie weiter an, dass die andere Person bereits die Änderungen, die zu A führen, zurück in die verschoben hat
Original-Repository, aus dem Sie beide das Original-Commit X bezogen haben.

Der von der anderen Person ausgeführte Push aktualisierte den Branch, der auf Commit X zeigte, auf
Punkt auf Commit A. Es ist ein schneller Vorlauf.

Aber wenn Sie versuchen zu pushen, werden Sie versuchen, den Branch (der jetzt auf A zeigt) mit . zu aktualisieren
begehen B. Das tut nicht schneller Vorlauf. Wenn Sie dies getan haben, werden die von Commit A eingeführten Änderungen
verloren gehen, weil jetzt alle anfangen, auf B zu bauen.

Der Befehl lässt standardmäßig kein Update zu, das kein Fast-Forward ist, um dies zu verhindern
Verlust der Geschichte.

Wenn Sie Ihre Arbeit (Historie von X nach B) oder die Arbeit der anderen Person nicht verlieren möchten
(Historie von X nach A), müssen Sie zuerst die Historie aus dem Repository holen,
Erstellen Sie eine Historie, die Änderungen enthält, die von beiden Parteien vorgenommen wurden, und verschieben Sie das Ergebnis zurück.

Sie können "git pull" ausführen, potenzielle Konflikte lösen und das Ergebnis "git push" ausführen. 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 wird im Schnellvorlauf durchgeführt und Ihr Push wird
akzeptiert.

Alternativ können Sie Ihren Wechsel zwischen X und B mit "git pull" auf A umbenennen
--rebase" und schiebe das Ergebnis zurück. Die Rebase erstellt einen neuen Commit D, der die
Wechsel zwischen X und B über A.

BD
/ /
---X---A

Auch hier wird A mit diesem Commit aktualisiert, und Ihr Push wird akzeptiert.

Es gibt eine weitere häufige Situation, in der Sie möglicherweise auf eine Ablehnung ohne Vorlauf stoßen, wenn
Sie versuchen zu pushen, und es ist möglich, selbst wenn Sie in ein Repository niemanden pushen
sonst dringt ein. Nachdem Sie Commit A selbst gedrückt haben (im ersten Bild in diesem Abschnitt),
Ersetzen Sie es durch "git commit --amend", um Commit B zu erzeugen, und Sie versuchen, es herauszuschieben.
weil vergessen, dass du A schon rausgedrückt hast. In einem solchen Fall und nur, wenn Sie es sind
sicher, dass in der Zwischenzeit niemand Ihr früheres Commit A geholt hat (und angefangen hat, darauf aufzubauen)
oben drauf), können Sie "git push --force" ausführen, um es zu überschreiben. Mit anderen Worten, "git push
--force" ist eine Methode, die für den Fall reserviert ist, in dem Sie den Verlauf verlieren möchten.

Beispiele:

Git drücken
Funktioniert wie git push , wo ist die Fernbedienung des aktuellen Zweigs (oder
origin, wenn für die aktuelle Verzweigung keine Gegenstelle konfiguriert ist).

git push Herkunft
Schiebt den Stromzweig ohne zusätzliche Konfiguration zum konfigurierten Upstream
(remote.origin.merge Konfigurationsvariable), wenn sie den gleichen Namen hat wie die aktuelle
Branch, und Fehler aus, ohne anders zu drücken.

Das Standardverhalten dieses Befehls, wenn nein gegeben ist kann konfiguriert werden durch
Einstellen der Push-Option der Fernbedienung oder der Konfigurationsvariablen push.default.

Um beispielsweise standardmäßig nur den aktuellen Branch zum Ursprung zu pushen, verwenden Sie git config
Remote.Ursprung.HEAD.drücken. Alle gültigen (wie die in den Beispielen unten) können
als Standard für git push origin konfiguriert werden.

git push origin:
Schieben Sie "passende" Zweige zum Ursprung. Sehen im Abschnitt OPTIONEN oben für a
Beschreibung von "passenden" Zweigen.

git push Ursprung Master
Finden Sie eine Referenz, die mit master im Quell-Repository übereinstimmt (höchstwahrscheinlich würde sie finden
refs/heads/master) und aktualisieren Sie dieselbe Referenz (z. B. refs/heads/master) im Ursprung
Depot damit. Wenn der Master nicht remote existierte, würde er erstellt.

git push origin HEAD
Eine praktische Möglichkeit, den aktuellen Zweig auf der Fernbedienung auf denselben Namen zu übertragen.

git push Mutterschiff master:satellite/master dev:satellite/dev
Verwenden Sie die Quellreferenz, die dem Master entspricht (zB refs/heads/master), um die Referenz zu aktualisieren
das entspricht Satellit/Master (höchstwahrscheinlich Refs/Remotes/Satellit/Master) im
Mutterschiff-Repository; Machen Sie dasselbe für dev und satellite/dev.

Dies dient dazu, den git fetch-Lauf auf dem Mutterschiff zu emulieren, indem git push verwendet wird, das im ausgeführt wird
entgegengesetzte Richtung, um die am Satelliten geleistete Arbeit zu integrieren, und ist oft
notwendig, wenn Sie nur eine Verbindung herstellen können (z. B. Satellit kann per SSH in
Mutterschiff, aber Mutterschiff kann keine Verbindung zum Satelliten herstellen, da letzterer
befindet sich hinter einer Firewall oder führt kein sshd aus).

Nachdem Sie diesen Git-Push auf dem Satellitencomputer ausgeführt haben, würden Sie per SSH in die
mothership und run git werden dort zusammengeführt, um die Emulation von git pull abzuschließen, die ausgeführt wurden
auf dem Mutterschiff, um die auf dem Satelliten vorgenommenen Änderungen abzurufen.

Git-Push-Ursprung HEAD:master
Pushen Sie den aktuellen Branch an den Remote-Ref-Matching-Master im Ursprungsrepository.
Dieses Formular ist praktisch, um den aktuellen Zweig zu pushen, ohne über seinen lokalen nachzudenken
Namen.

git push origin master:refs/heads/experimental
Erstellen Sie den experimentellen Zweig im Origin-Repository, indem Sie den aktuellen Master kopieren
Zweig. Dieses Formular wird nur benötigt, um einen neuen Branch oder Tag in der Fernbedienung zu erstellen
Repository, wenn der lokale Name und der entfernte Name unterschiedlich sind; andernfalls ist die ref
Name allein wird funktionieren.

git push origin :experimentell
Suchen Sie eine Referenz, die im Ursprungs-Repository mit experimentell übereinstimmt (z. B.
refs/heads/experimental) und löschen Sie es.

git push origin +dev:master
Aktualisieren Sie den Master-Zweig des Ursprungs-Repositorys mit dem dev-Zweig, so dass
Nicht-Fast-Forward-Updates. Dieser können. verlassen nicht referenziert verpflichtet baumelnd in Herkunft
Repository. Betrachten Sie die folgende Situation, in der ein schneller Vorlauf nicht möglich ist:

o---o---o---A---B Herkunft/Meister
\
X---Y---Z Abw

Der obige Befehl würde das Ursprungs-Repository ändern in

A---B (unbenannter Zweig)
/
o---o---o---X---Y---Z Master

Die Commits A und B würden nicht mehr zu einem Zweig mit symbolischem Namen gehören, und auch
unerreichbar sein. Als solche würden diese Commits durch einen git gc-Befehl auf dem . entfernt
Ursprungs-Repository.

GIT

Ein Teil des git(1) Suite

Verwenden Sie git-push online mit den onworks.net-Diensten