git-receive-pack – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-receive-pack – Empfangen Sie, was in das Repository gepusht wird

ZUSAMMENFASSUNG

Git-Receive-Pack

BESCHREIBUNG

Aufgerufen von git Paket senden und aktualisiert das Repository mit den aus dem bereitgestellten Informationen
entferntes Ende.

Dieser Befehl wird normalerweise nicht direkt vom Endbenutzer aufgerufen. Die Benutzeroberfläche für das Protokoll ist
auf die git Paket senden Seite, und das Programmpaar soll zum Pushen von Updates verwendet werden
Remote-Repository. Informationen zu Pull-Vorgängen finden Sie unter Git-Fetch-Pack(1).

Der Befehl ermöglicht die Erstellung und den schnellen Vorlauf von sha1-Referenzen (Heads/Tags) auf dem
entferntes Ende (streng genommen ist es das lokale Ende). Git-Receive-Pack läuft, aber für den Benutzer
Wer am Send-Pack-Ende sitzt, aktualisiert die Fernbedienung. Verwirrt?)

Weitere Beispiele aus der Praxis für die Verwendung von Update- und Post-Update-Hooks finden Sie im
Dokumentations-/Howto-Verzeichnis.

Git-Receive-Pack berücksichtigt die Konfigurationsoption „receive.denyNonFastForwards“, die ihr mitteilt, ob
Aktualisierungen einer Referenz sollten abgelehnt werden, wenn es sich nicht um einen schnellen Vorlauf handelt.

OPTIONAL

Das Repository, mit dem synchronisiert werden soll.

VOREMPFANG HOOK

Bevor eine Referenz aktualisiert wird, gilt: Wenn die Datei $GIT_DIR/hooks/pre-receive vorhanden und ausführbar ist, wird sie aktualisiert
wird einmalig ohne Parameter aufgerufen. Die Standardeingabe des Hooks ist eine Zeile
pro Referenz, die aktualisiert werden soll:

sha1-old SP sha1-new SP refname LF

Der Refname-Wert ist relativ zu $GIT_DIR; zB für den Hauptkopf ist dies der Fall
„refs/heads/master“. Die beiden sha1-Werte vor jedem Referenznamen sind die Objektnamen für die
refname vor und nach dem Update. Zu erstellende Refs haben sha1-old gleich 0{40},
während zu löschende Refs sha1-new gleich 0{40} haben, andernfalls sha1-old und
sha1-new sollten gültige Objekte im Repository sein.

Beim Akzeptieren eines signierten Pushs (siehe Git-Push(1)) wird das signierte Push-Zertifikat in a gespeichert
Blob und eine Umgebungsvariable GIT_PUSH_CERT können für ihren Objektnamen herangezogen werden. Sehen
Die Beschreibung des Post-Receive-Hooks dient als Beispiel. Darüber hinaus ist das Zertifikat
mit GPG verifiziert und das Ergebnis wird mit den folgenden Umgebungsvariablen exportiert:

GIT_PUSH_CERT_SIGNER
Der Name und die E-Mail-Adresse des Besitzers des Schlüssels, der den Push signiert hat
Zertifikat.

GIT_PUSH_CERT_KEY
Die GPG-Schlüssel-ID des Schlüssels, der das Push-Zertifikat signiert hat.

GIT_PUSH_CERT_STATUS
Der Status der GPG-Überprüfung des Push-Zertifikats unter Verwendung derselben Mnemonik wie
in %G verwendet? Format der Git-Log-Befehlsfamilie (siehe Git-Log(1)).

GIT_PUSH_CERT_NONCE
Die Nonce-Zeichenfolge, die der Prozess vom Unterzeichner in das Push-Zertifikat aufnehmen wollte. Wenn
Dies stimmt nicht mit dem Wert überein, der im „Nonce“-Header im Push-Zertifikat aufgezeichnet ist.
Dies kann darauf hinweisen, dass es sich bei dem Zertifikat um ein gültiges Zertifikat handelt, das von einem wiedergegeben wird
separate „Git Push“-Sitzung.

GIT_PUSH_CERT_NONCE_STATUS

UNAUFGEFORDERT
„git push --signed“ hat eine Nonce gesendet, obwohl wir nicht darum gebeten haben, eine zu senden.

FEHLT
„git push --signed“ hat keinen Nonce-Header gesendet.

BAD
„git push --signed“ hat eine falsche Nonce gesendet.

OK
„git push --signed“ hat die Nonce gesendet, die wir gesendet haben.

SLOP
„git push --signed“ hat eine Nonce gesendet, die sich von der unterscheidet, die wir jetzt gesendet haben, aber
in einer früheren Sitzung. Siehe Umgebungsvariable GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
„git push --signed“ hat eine andere Nonce gesendet als die, die wir jetzt gesendet haben, aber in einer
andere Sitzung, deren Startzeit sich um diese viele Sekunden von der unterscheidet
aktuelle Sitzung. Nur sinnvoll, wenn GIT_PUSH_CERT_NONCE_STATUS SLOP sagt. Lesen Sie auch
über die Variable „receive.certNonceSlop“ in git-config(1).

Dieser Hook wird aufgerufen, bevor ein Referenzname aktualisiert wird und bevor Schnellvorlaufprüfungen durchgeführt werden
durchgeführt.

Wenn der Pre-Receive-Hook mit einem Exit-Status ungleich Null beendet wird, werden keine Aktualisierungen durchgeführt.
und die Update-, Post-Receive- und Post-Update-Hooks werden ebenfalls nicht aufgerufen. Das kann sein
nützlich, um schnell auszuhelfen, wenn das Update nicht unterstützt werden soll.

AKTUALISIEREN HOOK

Bevor jede Referenz aktualisiert wird, gilt: Wenn die Datei $GIT_DIR/hooks/update vorhanden und ausführbar ist, ist sie vorhanden
Wird einmal pro Referenz mit drei Parametern aufgerufen:

$GIT_DIR/hooks/update refname sha1-old sha1-new

Der Refname-Parameter ist relativ zu $GIT_DIR; zB für den Hauptkopf ist dies der Fall
„refs/heads/master“. Die beiden sha1-Argumente sind die Objektnamen für den Referenznamen davor
und nach dem Update. Beachten Sie, dass der Hook aufgerufen wird, bevor der Referenzname aktualisiert wird
Entweder ist sha1-old 0{40} (was bedeutet, dass es noch keinen solchen Verweis gibt), oder es sollte mit dem übereinstimmen, was ist
in refname aufgezeichnet.

Der Hook sollte mit einem Status ungleich Null beendet werden, wenn er die Aktualisierung der benannten Referenz nicht zulassen möchte.
Andernfalls sollte es mit Null beendet werden.

Eine erfolgreiche Ausführung (ein Null-Exit-Status) dieses Hooks stellt nicht sicher, dass der Verweis ausgeführt wird
tatsächlich aktualisiert werden, ist dies nur eine Voraussetzung. Daher ist es keine gute Idee, es zu verschicken
Benachrichtigungen (z. B. E-Mail) von diesem Hook. Erwägen Sie stattdessen die Verwendung des Post-Receive-Hooks.

POST-ERHALT HOOK

Nachdem alle Referenzen aktualisiert wurden (oder versucht wurden, aktualisiert zu werden), falls eine Referenzaktualisierung durchgeführt wurde
erfolgreich, und wenn die Datei $GIT_DIR/hooks/post-receive vorhanden und ausführbar ist, wird dies der Fall sein
einmalig ohne Parameter aufgerufen. Die Standardeingabe des Hooks ist jeweils eine Zeile
Referenz erfolgreich aktualisiert:

sha1-old SP sha1-new SP refname LF

Der Refname-Wert ist relativ zu $GIT_DIR; zB für den Hauptkopf ist dies der Fall
„refs/heads/master“. Die beiden sha1-Werte vor jedem Referenznamen sind die Objektnamen für die
refname vor und nach dem Update. Für erstellte Refs ist sha1-old gleich
0{40}, während gelöschte Refs sha1-new gleich 0{40} haben, andernfalls sha1-old
und sha1-new sollten gültige Objekte im Repository sein.

Die Umgebungsvariablen GIT_PUSH_CERT* können wie beim Pre-Receive-Hook überprüft werden.
nach Annahme eines unterschriebenen Pushs.

Mit diesem Hook ist es einfach, E-Mails zu generieren, die die Aktualisierungen des Repositorys beschreiben.
Dieses Beispielskript sendet eine E-Mail-Nachricht pro Referenz, in der die an die übertragenen Commits aufgeführt sind
Repository und protokolliert die Push-Zertifikate signierter Pushs mit guten Signaturen in einem
Loggerservice:

#!/ Bin / sh
# Commit-Update-Informationen verschicken.
während gelesen oval nval ref
do
if expr "$oval" : '0*$' >/dev/null
dann
echo „Neue Referenz mit den folgenden Commits erstellt:“
git rev-list --pretty „$nval“
sonst
echo „Neue Commits:“
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s „Änderungen an ref $ref“ commit-list@mydomain
erledigt
# signiertes Push-Zertifikat protokollieren, falls vorhanden
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
dann
(
Echo erwartete Nonce ist ${GIT_PUSH_NONCE}
Git-Cat-File-Blob ${GIT_PUSH_CERT}
) | mail -s „Push-Zertifikat von $GIT_PUSH_CERT_SIGNER“ push-log@mydomain
fi
Beenden Sie 0

Der Exit-Code dieses Hook-Aufrufs wird ignoriert, ein Exit-Code ungleich Null jedoch
eine Fehlermeldung generieren.

Beachten Sie, dass refname möglicherweise nicht über sha1-new verfügt, wenn dieser Hook ausgeführt wird. Das kann
Dies kann leicht passieren, wenn ein anderer Benutzer die Referenz ändert, nachdem sie von aktualisiert wurde Git-Receive-Pack,
aber bevor der Haken es bewerten konnte. Es wird empfohlen, dass Hooks auf sha1-new basieren
anstelle des aktuellen Werts von refname.

POST-UPDATE HOOK

Nach allen anderen Verarbeitungen, ob mindestens eine Referenz aktualisiert wurde und wenn
Die Datei $GIT_DIR/hooks/post-update existiert und ist ausführbar, dann wird post-update aufgerufen
mit der Liste der aktualisierten Referenzen. Damit kann jedes beliebige Repository implementiert werden
umfangreiche Aufräumarbeiten.

Der Exit-Code dieses Hook-Aufrufs wird ignoriert; das Einzige, was noch übrig bleibt
Git-Receive-Pack An diesem Punkt muss man sich ohnehin selbst verlassen.

Dieser Hook kann beispielsweise verwendet werden, um git update-server-info auszuführen, wenn das Repository vorhanden ist
verpackt und wird über einen Dump-Transport serviert.

#!/ Bin / sh
exec git update-server-info

Verwenden Sie git-receive-pack online über die Dienste von onworks.net