English ▾ Themen ▾ Neueste Version ▾ git-receive-pack zuletzt aktualisiert in 2.50.0

NAME

git-receive-pack - Empfängt, was in das Repository gepusht wurde

SYNOPSIS

git receive-pack <git-dir>

BESCHREIBUNG

Wird von git send-pack aufgerufen und aktualisiert das Repository mit den Informationen, die vom Remote-Ende übermittelt wurden.

Dieser Befehl wird normalerweise nicht direkt vom Endbenutzer aufgerufen. Die Benutzeroberfläche für das Protokoll befindet sich auf der Seite von git send-pack, und das Programm-Paar ist dazu gedacht, Updates an ein Remote-Repository zu pushen. Für Pull-Operationen siehe git-fetch-pack[1].

Der Befehl ermöglicht die Erstellung und das Fast-Forwarding von SHA1-Refs (Heads/Tags) am Remote-Ende (genauer gesagt, es ist das lokale Ende, auf dem git-receive-pack läuft, aber für den Benutzer, der am send-pack-Ende sitzt, aktualisiert es das Remote. Verwirrt?)

Weitere reale Beispiele für die Verwendung von Update- und Post-Update-Hooks finden Sie im Verzeichnis Documentation/howto.

git-receive-pack beachtet die Konfigurationsoption receive.denyNonFastForwards, die angibt, ob Updates einer Ref verweigert werden sollen, wenn sie keine Fast-Forwards sind.

Eine Reihe weiterer receive.* Konfigurationsoptionen stehen zur Verfügung, um sein Verhalten anzupassen. Siehe git-config[1].

OPTIONEN

<git-dir>

Das Repository, in das synchronisiert werden soll.

--http-backend-info-refs

Wird von git-http-backend[1] verwendet, um $GIT_URL/info/refs?service=git-receive-pack-Anfragen zu bedienen. Siehe --http-backend-info-refs in git-upload-pack[1].

--skip-connectivity-check

Umgeht die Konnektivitätsprüfungen, die die Existenz aller Objekte im transitiven Abschluss erreichbarer Objekte validieren. Diese Option ist für Serverbetreiber gedacht, die ihre eigene Überprüfung der Objektkonnektivität außerhalb von Git implementieren möchten. Dies ist nützlich in Fällen, in denen der Server zusätzliche Informationen darüber hat, wie Git verwendet wird, und somit auf bestimmte Garantien vertrauen kann, um die Objektkonnektivität effizienter zu berechnen, als Git selbst es kann. Die Verwendung dieser Option ohne einen zuverlässigen externen Mechanismus zur Gewährleistung der vollständigen Konnektivität erreichbarer Objekte birgt das Risiko einer Beschädigung des Repositories und sollte im allgemeinen Fall nicht verwendet werden.

PRE-RECEIVE HOOK

Bevor eine Ref aktualisiert wird, wird, wenn die Datei $GIT_DIR/hooks/pre-receive existiert und ausführbar ist, diese einmal ohne Parameter aufgerufen. Die Standardeingabe des Hooks ist eine Zeile pro zu aktualisierender Ref.

sha1-old SP sha1-new SP refname LF

Der Wert refname ist relativ zu $GIT_DIR; z.B. für den Master-Head ist dies "refs/heads/master". Die beiden SHA1-Werte vor jedem refname sind die Objektbezeichnungen für den refname vor und nach der Aktualisierung. Refs, die erstellt werden sollen, haben sha1-old gleich 0{40}, während refs, die gelöscht werden sollen, sha1-new gleich 0{40} haben. Andernfalls sollten sha1-old und sha1-new gültige Objekte im Repository sein.

Beim Akzeptieren eines signierten Pushs (siehe git-push[1]) wird das signierte Push-Zertifikat in einem Blob gespeichert und eine Umgebungsvariable GIT_PUSH_CERT kann für dessen Objektbezeichnung konsultiert werden. Siehe die Beschreibung des post-receive Hooks für ein Beispiel. Zusätzlich wird das Zertifikat mit GPG verifiziert und das Ergebnis mit den folgenden Umgebungsvariablen exportiert:

GIT_PUSH_CERT_SIGNER

Der Name und die E-Mail-Adresse des Eigentümers des Schlüssels, der das Push-Zertifikat signiert hat.

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-Verifizierung des Push-Zertifikats, unter Verwendung derselben Mnemotechnik wie im %G? Format der git log-Befehlsfamilie (siehe git-log[1]).

GIT_PUSH_CERT_NONCE

Der Nonce-String, den der Prozess den Signierer aufforderte, in das Push-Zertifikat aufzunehmen. Wenn dieser nicht mit dem Wert übereinstimmt, der im "nonce"-Header des Push-Zertifikats aufgezeichnet ist, kann dies darauf hindeuten, dass das Zertifikat ein gültiges ist, das aus einer separaten "git push"-Sitzung wiedergegeben wird.

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

"git push --signed" sendete eine Nonce, obwohl wir keine senden wollten.

MISSING

"git push --signed" sendete keinen Nonce-Header.

BAD

"git push --signed" sendete eine ungültige Nonce.

OK

"git push --signed" sendete die Nonce, die wir angefordert hatten.

SLOP

"git push --signed" sendete eine Nonce, die von der angeforderten abweicht, aber aus einer früheren Sitzung stammt. Siehe Umgebungsvariable GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP

"git push --signed" sendete eine Nonce, die von der angeforderten abweicht, aber aus einer anderen Sitzung stammt, deren Startzeit sich um diese Anzahl von Sekunden von der aktuellen Sitzung unterscheidet. Nur aussagekräftig, wenn GIT_PUSH_CERT_NONCE_STATUS SLOP angibt. Lesen Sie auch über die Variable receive.certNonceSlop in git-config[1].

Dieser Hook wird aufgerufen, bevor irgendeine Ref-Aktualisierung stattfindet und bevor irgendwelche Fast-Forward-Prüfungen durchgeführt werden.

Wenn der pre-receive Hook mit einem nicht-null Exit-Status beendet wird, werden keine Aktualisierungen vorgenommen, und die Hooks update, post-receive und post-update werden ebenfalls nicht aufgerufen. Dies kann nützlich sein, um schnell auszusteigen, wenn die Aktualisierung nicht unterstützt werden soll.

Siehe die Hinweise zur Quarantäne-Umgebung unten.

UPDATE HOOK

Bevor jede Ref aktualisiert wird, wird, wenn die Datei $GIT_DIR/hooks/update existiert und ausführbar ist, diese einmal pro Ref mit drei Parametern aufgerufen:

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

Der Parameter refname ist relativ zu $GIT_DIR; z.B. für den Master-Head ist dies "refs/heads/master". Die beiden SHA1-Argumente sind die Objektbezeichnungen für den refname vor und nach der Aktualisierung. Beachten Sie, dass der Hook aufgerufen wird, bevor der refname aktualisiert wird, sodass entweder sha1-old 0{40} ist (was bedeutet, dass es diese Ref noch nicht gibt) oder er mit dem übereinstimmen sollte, was in refname aufgezeichnet ist.

Der Hook sollte mit einem nicht-null Exit-Status beendet werden, wenn er die Aktualisierung der benannten Ref verweigern möchte. Andernfalls sollte er mit null beendet werden.

Eine erfolgreiche Ausführung (ein null Exit-Status) dieses Hooks stellt nicht sicher, dass die Ref tatsächlich aktualisiert wird; es ist nur eine Voraussetzung. Daher ist es keine gute Idee, Benachrichtigungen (z.B. E-Mails) von diesem Hook aus zu senden. Betrachten Sie stattdessen die Verwendung des post-receive Hooks.

POST-RECEIVE HOOK

Nachdem alle Refs aktualisiert wurden (oder versucht wurden zu aktualisieren), wird, wenn eine Ref-Aktualisierung erfolgreich war und wenn die Datei $GIT_DIR/hooks/post-receive existiert und ausführbar ist, diese einmal ohne Parameter aufgerufen. Die Standardeingabe des Hooks ist eine Zeile für jede erfolgreich aktualisierte Ref.

sha1-old SP sha1-new SP refname LF

Der Wert refname ist relativ zu $GIT_DIR; z.B. für den Master-Head ist dies "refs/heads/master". Die beiden SHA1-Werte vor jedem refname sind die Objektbezeichnungen für den refname vor und nach der Aktualisierung. Refs, die erstellt wurden, haben sha1-old gleich 0{40}, während Refs, die gelöscht wurden, sha1-new gleich 0{40} haben. Andernfalls sollten sha1-old und sha1-new gültige Objekte im Repository sein.

Die Umgebungsvariablen GIT_PUSH_CERT* können, genau wie im pre-receive Hook, nach dem Akzeptieren eines signierten Pushs inspiziert werden.

Mit diesem Hook ist es einfach, E-Mails zu generieren, die die Aktualisierungen des Repositories beschreiben. Dieses Beispielskript sendet eine E-Mail pro Ref, die die in das Repository gepushten Commits auflistet, und protokolliert die Push-Zertifikate von signierten Pushs mit gültigen Signaturen an einen Logger-Service.

#!/bin/sh
# mail out commit update information.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Created a new ref, with the following commits:"
		git rev-list --pretty "$nval"
	else
		echo "New commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Changes to ref $ref" commit-list@mydomain
done
# log signed push certificate, if any
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
	(
		echo expected nonce is ${GIT_PUSH_NONCE}
		git cat-file blob ${GIT_PUSH_CERT}
	) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

Der Exit-Code dieses Hook-Aufrufs wird ignoriert; ein nicht-null Exit-Code erzeugt jedoch eine Fehlermeldung.

Beachten Sie, dass es möglich ist, dass refname kein sha1-new hat, wenn dieser Hook läuft. Dies kann leicht passieren, wenn ein anderer Benutzer die Ref modifiziert, nachdem sie von git-receive-pack aktualisiert wurde, aber bevor der Hook sie auswerten konnte. Es wird empfohlen, dass Hooks sich auf sha1-new verlassen und nicht auf den aktuellen Wert von refname.

POST-UPDATE HOOK

Nach aller anderen Verarbeitung, wenn mindestens eine Ref aktualisiert wurde und wenn die Datei $GIT_DIR/hooks/post-update existiert und ausführbar ist, wird post-update mit der Liste der aktualisierten Refs aufgerufen. Dies kann verwendet werden, um Repository-weite Bereinigungsaufgaben zu implementieren.

Der Exit-Code dieses Hook-Aufrufs wird ignoriert; es gibt für git-receive-pack an diesem Punkt nichts mehr zu tun, als selbst zu beenden.

Dieser Hook kann zum Beispiel verwendet werden, um git update-server-info auszuführen, wenn das Repository gepackt ist und über einen Dumb-Transport bedient wird.

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

QUARANTINE UMGEBUNG

Wenn receive-pack Objekte entgegennimmt, werden diese in ein temporäres "Quarantäne"-Verzeichnis innerhalb des Verzeichnisses $GIT_DIR/objects gelegt und erst in den Hauptobjektspeicher migriert, nachdem der pre-receive Hook abgeschlossen ist. Wenn der Push vorher fehlschlägt, wird das temporäre Verzeichnis vollständig entfernt.

Dies hat einige benutzerseitige Effekte und Einschränkungen:

  1. Pushes, die aufgrund von Problemen mit dem eingehenden Pack, fehlenden Objekten oder aufgrund des pre-receive Hooks fehlschlagen, hinterlassen keine Daten auf der Festplatte. Dies ist normalerweise hilfreich, um zu verhindern, dass wiederholte fehlgeschlagene Pushes Ihre Festplatte füllen, kann aber die Fehlersuche erschweren.

  2. Alle vom pre-receive Hook erstellten Objekte werden im Quarantäne-Verzeichnis erstellt (und nur migriert, wenn er erfolgreich ist).

  3. Der pre-receive Hook DARF KEINE Refs auf Quarantäne-Objekte verweisen lassen. Andere Programme, die auf das Repository zugreifen, können die Objekte nicht sehen (und wenn der pre-receive Hook fehlschlägt, würden diese Refs beschädigt werden). Zur Sicherheit werden alle Ref-Aktualisierungen aus pre-receive automatisch zurückgewiesen.

SIEHE AUCH

git-send-pack[1], gitnamespaces[7]

GIT

Teil der git[1] Suite