Einrichtung und Konfiguration
Projekte holen und erstellen
Grundlegende Snapshots
Branching und Merging
Projekte teilen und aktualisieren
Inspektion und Vergleich
Patching
Debugging
Externe Systeme
Server-Administration
Anleitungen
- gitattributes
- Konventionen der Kommandozeile
- Tägliches Git
- Häufig gestellte Fragen (FAQ)
- Glossar
- Hooks
- gitignore
- gitmodules
- Revisionen
- Submodule
- Tutorial
- Workflows
- Alle Anleitungen...
Administration
Plumbing-Befehle
- 2.46.1 → 2.52.0 keine Änderungen
-
2.46.0
2024-07-29
- 2.43.1 → 2.45.4 keine Änderungen
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 keine Änderungen
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 keine Änderungen
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 keine Änderungen
-
2.40.0
2023-03-12
- 2.39.1 → 2.39.5 keine Änderungen
-
2.39.0
2022-12-12
- 2.35.1 → 2.38.5 keine Änderungen
-
2.35.0
2022-01-24
- 2.32.1 → 2.34.8 keine Änderungen
-
2.32.0
2021-06-06
- 2.27.1 → 2.31.8 keine Änderungen
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 keine Änderungen
-
2.25.0
2020-01-13
- 2.1.4 → 2.24.4 keine Änderungen
-
2.0.5
2014-12-17
BESCHREIBUNG
Git verfügt über eine interne Schnittstelle zum Speichern und Abrufen von Anmeldedaten von systemspezifischen Helfern sowie zum Abfragen des Benutzers nach Benutzernamen und Passwörtern. Der Befehl git-credential stellt diese Schnittstelle für Skripte bereit, die Anmeldedaten auf die gleiche Weise wie Git abrufen, speichern oder abfragen möchten. Das Design dieser skriptfähigen Schnittstelle orientiert sich an der internen C-API. Weitere Hintergrundinformationen zu den Konzepten finden Sie in credential.h.
git-credential nimmt eine "action"-Option auf der Kommandozeile (eine von fill, approve oder reject) entgegen und liest eine Beschreibung der Anmeldedaten von stdin (siehe EIN-/AUSGABEFORMAT).
Wenn die Aktion fill ist, versucht git-credential, die Attribute "username" und "password" zur Beschreibung hinzuzufügen, indem es Konfigurationsdateien liest, konfigurierte Anmeldedaten-Helfer kontaktiert oder den Benutzer auffordert. Die Attribute "username" und "password" der Anmeldedatenbeschreibung werden dann zusammen mit den bereits bereitgestellten Attributen nach stdout ausgegeben.
Wenn die Aktion approve ist, sendet git-credential die Beschreibung an alle konfigurierten Anmeldedaten-Helfer, die die Anmeldedaten für die spätere Verwendung speichern können.
Wenn die Aktion reject ist, sendet git-credential die Beschreibung an alle konfigurierten Anmeldedaten-Helfer, die übereinstimmende gespeicherte Anmeldedaten löschen können.
Wenn die Aktion capability ist, kündigt git-credential alle unterstützten Fähigkeiten auf der Standardausgabe an.
Wenn die Aktion approve oder reject ist, sollte keine Ausgabe erfolgen.
TYPISCHE VERWENDUNG VON GIT CREDENTIAL
Eine Anwendung, die git-credential verwendet, wird typischerweise git credential nach folgenden Schritten verwenden:
-
Generieren einer Beschreibung der Anmeldedaten basierend auf dem Kontext.
Wenn wir beispielsweise ein Passwort für
https://example.com/foo.gitbenötigen, könnten wir die folgende Beschreibung der Anmeldedaten generieren (vergessen Sie nicht die Leerzeile am Ende; sie teiltgitcredentialmit, dass die Anwendung das Einspeisen aller verfügbaren Informationen beendet hat)protocol=https host=example.com path=foo.git
-
Fordern Sie git-credential auf, uns einen Benutzernamen und ein Passwort für diese Beschreibung zu geben. Dies geschieht durch Ausführen von
gitcredentialfill, wobei die Beschreibung aus Schritt (1) an seine Standardeingabe übergeben wird. Die vollständige Beschreibung der Anmeldedaten (einschließlich der Anmeldedaten selbst, d. h. Login und Passwort) wird auf der Standardausgabe ausgegeben, wie z. B.:protocol=https host=example.com username=bob password=secr3t
In den meisten Fällen werden die in der Eingabe angegebenen Attribute in der Ausgabe wiederholt, aber Git kann die Beschreibung der Anmeldedaten auch ändern, z. B. durch Entfernen des
path-Attributs, wenn das Protokoll HTTP(s) ist undcredential.useHttpPathfalsch ist.Wenn
gitcredentialdas Passwort kannte, war dieser Schritt möglicherweise nicht mit der tatsächlichen Eingabe des Passworts durch den Benutzer verbunden (der Benutzer hat möglicherweise stattdessen ein Passwort zur Entsperrung des Schlüsselbunds eingegeben oder es wurde keine Benutzerinteraktion durchgeführt, wenn der Schlüsselbund bereits entsperrt war), bevor erpassword=secr3tzurückgab. -
Verwenden Sie die Anmeldedaten (z. B. greifen Sie mit dem Benutzernamen und dem Passwort aus Schritt (2) auf die URL zu) und prüfen Sie, ob sie akzeptiert werden.
-
Melden Sie den Erfolg oder Misserfolg des Passworts. Wenn die Anmeldedaten den Vorgang erfolgreich abschließen konnten, können sie mit der Aktion "approve" markiert werden, um
gitcredentialanzuweisen, sie bei der nächsten Aufrufung wiederzuverwenden. Wenn die Anmeldedaten während des Vorgangs abgelehnt wurden, verwenden Sie die Aktion "reject", damitgitcredentialbei der nächsten Aufrufung nach einem neuen Passwort fragt. In beiden Fällen solltegitcredentialmit der aus Schritt (2) erhaltenen Beschreibung der Anmeldedaten (die auch die in Schritt (1) bereitgestellten Felder enthält) gespeist werden.
EIN-/AUSGABEFORMAT
git credential liest und/oder schreibt (abhängig von der verwendeten Aktion) Informationen zu Anmeldedaten in seine Standardeingabe/-ausgabe. Diese Informationen können sich entweder auf Schlüssel beziehen, für die git credential die Anmeldeinformationen (z. B. Host, Protokoll, Pfad) abruft, oder auf die eigentlichen abzurufenden Anmeldedaten (Benutzername/Passwort).
Die Anmeldedaten sind in eine Reihe benannter Attribute aufgeteilt, mit einem Attribut pro Zeile. Jedes Attribut wird durch ein Schlüssel-Wert-Paar angegeben, getrennt durch ein = (Gleichheitszeichen), gefolgt von einem Zeilenumbruch.
Der Schlüssel kann beliebige Bytes außer =, Zeilenumbruch oder NUL enthalten. Der Wert kann beliebige Bytes außer Zeilenumbruch oder NUL enthalten. Eine Zeile, einschließlich des abschließenden Zeilenumbruchs, darf nicht länger als 65535 Bytes sein, um eine effiziente Analyse durch Implementierungen zu ermöglichen.
Attribute mit Schlüsseln, die auf C-Style-Klammern [] enden, können mehrere Werte haben. Jede Instanz eines mehrwertigen Attributs bildet eine geordnete Liste von Werten – die Reihenfolge der wiederholten Attribute bestimmt die Reihenfolge der Werte. Ein leeres mehrwertiges Attribut (key[]=\n) löscht alle vorherigen Einträge und setzt die Liste zurück.
In allen Fällen werden alle Bytes so behandelt, wie sie sind (d. h. es gibt kein Quoting, und man kann keinen Wert mit einem Zeilenumbruch oder NUL darin übertragen). Die Liste der Attribute wird durch eine Leerzeile oder das Ende der Datei beendet.
Git versteht die folgenden Attribute:
protocol-
Das Protokoll, über das die Anmeldedaten verwendet werden (z. B.
https). host-
Der Remote-Hostname für eine Netzwerkanmeldedaten. Dies schließt die Portnummer ein, falls eine angegeben wurde (z. B. "example.com:8088").
path-
Der Pfad, mit dem die Anmeldedaten verwendet werden. Z. B. für den Zugriff auf ein entferntes https-Repository ist dies der Pfad des Repositories auf dem Server.
username-
Der Benutzername der Anmeldedaten, falls wir bereits einen haben (z. B. aus einer URL, der Konfiguration, dem Benutzer oder von einem zuvor ausgeführten Helfer).
password-
Das Passwort der Anmeldedaten, falls wir es speichern lassen.
password_expiry_utc-
Generierte Passwörter wie OAuth-Zugriffstoken können ein Ablaufdatum haben. Beim Lesen von Anmeldedaten von Helfern ignoriert
gitcredentialfillabgelaufene Passwörter. Dargestellt als Unix-Zeit UTC, Sekunden seit 1970. oauth_refresh_token-
Ein OAuth-Refresh-Token kann ein Passwort begleiten, das ein OAuth-Zugriffstoken ist. Helfer müssen dieses Attribut wie das Passwort-Attribut vertraulich behandeln. Git selbst hat kein spezielles Verhalten für dieses Attribut.
url-
Wenn dieses spezielle Attribut von
gitcredentialgelesen wird, wird der Wert als URL analysiert und so behandelt, als ob seine Bestandteile gelesen worden wären (z. B. würdeurl=https://example.comsich so verhalten, als wärenprotocol=httpsundhost=example.combereitgestellt worden). Dies kann Aufrufern helfen, URLs selbst zu parsen.Beachten Sie, dass die Angabe eines Protokolls obligatorisch ist und wenn die URL keinen Hostnamen angibt (z. B. "cert:///path/to/file"), die Anmeldedaten ein Hostnamenattribut enthalten, dessen Wert eine leere Zeichenkette ist.
In der URL fehlende Komponenten (z. B. gibt es im obigen Beispiel keinen Benutzernamen) bleiben unbesetzt.
authtype-
Dies zeigt an, dass das betreffende Authentifizierungsschema verwendet werden soll. Gängige Werte für HTTP und HTTPS sind
basic,bearerunddigest, wobei letzteres unsicher ist und nicht verwendet werden sollte. Wenncredentialverwendet wird, kann dies auf eine beliebige Zeichenkette gesetzt werden, die für das betreffende Protokoll (normalerweise HTTP) geeignet ist.Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.
credential-
Die vorcodierten Anmeldedaten, die für das betreffende Protokoll (normalerweise HTTP) geeignet sind. Wenn dieser Schlüssel gesendet wird, ist
authtypeobligatorisch, undusernameundpasswordwerden nicht verwendet. Für HTTP verkettet Git denauthtype-Wert und diesen Wert mit einem einzelnen Leerzeichen, um denAuthorization-Header zu ermitteln.Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.
ephemeral-
Dieser boolesche Wert gibt an, wenn er wahr ist, dass der Wert im Feld
credentialnicht vom Anmeldedaten-Helfer gespeichert werden sollte, da seine Nützlichkeit zeitlich begrenzt ist. Zum Beispiel wird ein HTTP-Digest-Anmeldedaten-Wert mit einer Nonce berechnet, und die Wiederverwendung führt nicht zu einer erfolgreichen Authentifizierung. Dies kann auch für kurzzeitige Anmeldedaten (z. B. 24 Stunden) verwendet werden. Der Standardwert ist false.Der Anmeldedaten-Helfer wird trotzdem mit
storeodereraseaufgerufen, damit er feststellen kann, ob der Vorgang erfolgreich war.Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.
state[]-
Dieser Wert liefert einen undurchsichtigen Zustand, der an diesen Helfer zurückgegeben wird, wenn er erneut aufgerufen wird. Jeder verschiedene Anmeldedaten-Helfer kann dies einmal angeben. Der Wert sollte ein Präfix enthalten, das für den Anmeldedaten-Helfer eindeutig ist, und Werte ignorieren, die nicht zu seinem Präfix passen.
Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.
continue-
Dies ist ein boolescher Wert, der, wenn er aktiviert ist, anzeigt, dass diese Authentifizierung ein nicht endgültiger Teil eines mehrstufigen Authentifizierungsschritts ist. Dies ist üblich bei Protokollen wie NTLM und Kerberos, bei denen zwei Runden der Client-Authentifizierung erforderlich sind, und das Setzen dieses Flags ermöglicht es dem Anmeldedaten-Helfer, den mehrstufigen Authentifizierungsschritt zu implementieren. Dieses Flag sollte nur gesendet werden, wenn eine weitere Stufe erforderlich ist; das heißt, wenn eine weitere Authentifizierungsrunde erwartet wird.
Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt. Dieses Attribut ist einseitig von einem Anmeldedaten-Helfer, um Informationen an Git (oder andere Programme, die
gitcredentialaufrufen) weiterzugeben. wwwauth[]-
Wenn eine HTTP-Antwort von Git empfangen wird, die einen oder mehrere WWW-Authenticate-Authentifizierungs-Header enthält, werden diese von Git an die Anmeldedaten-Helfer weitergeleitet.
Jeder WWW-Authenticate-Header-Wert wird als mehrwertiges Attribut wwwauth[] übergeben, wobei die Reihenfolge der Attribute der Reihenfolge entspricht, in der sie in der HTTP-Antwort erscheinen. Dieses Attribut ist einseitig von Git, um zusätzliche Informationen an Anmeldedaten-Helfer weiterzugeben.
capability[]-
Dies signalisiert, dass Git oder der Helfer, je nach Fall, die betreffende Fähigkeit unterstützt. Dies kann verwendet werden, um bessere, spezifischere Daten als Teil des Protokolls bereitzustellen. Eine
capability[]-Direktive muss jedem Wert vorausgehen, der von ihr abhängt, und diese Direktiven sollten der erste im Protokoll angekündigte Punkt sein.Es gibt zwei derzeit unterstützte Fähigkeiten. Die erste ist
authtype, die anzeigt, dass die Werteauthtype,credentialundephemeralverstanden werden. Die zweite iststate, die anzeigt, dass die Wertestate[] undcontinueverstanden werden.Es ist nicht obligatorisch, die zusätzlichen Funktionen zu nutzen, nur weil die Fähigkeit unterstützt wird, aber sie sollten nicht ohne die Fähigkeit bereitgestellt werden.
Nicht erkannte Attribute und Fähigkeiten werden stillschweigend verworfen.
FÄHIGKEITEN EIN-/AUSGABEFORMAT
Für git credential capability ist das Format etwas anders. Zuerst wird eine Ankündigung version 0 gemacht, um die aktuelle Version des Protokolls anzuzeigen, und dann wird jede Fähigkeit mit einer Zeile wie capability authtype angekündigt. Anmeldedaten-Helfer können dieses Format ebenfalls implementieren, wiederum mit dem Argument capability. Zukünftig können weitere Zeilen hinzugefügt werden; Aufrufer sollten Zeilen ignorieren, die sie nicht verstehen.
Da dies ein neuer Teil des Anmeldedaten-Helfer-Protokolls ist, werden ältere Versionen von Git sowie einige Anmeldedaten-Helfer es möglicherweise nicht unterstützen. Wenn ein Nicht-Null-Exit-Status empfangen wird oder wenn die erste Zeile nicht mit dem Wort version und einem Leerzeichen beginnt, sollten Aufrufer davon ausgehen, dass keine Fähigkeiten unterstützt werden.
Die Absicht dieses Formats besteht darin, es eindeutig vom Anmeldedaten-Output zu unterscheiden. Es ist möglich, sehr einfache Anmeldedaten-Helfer (z. B. Inline-Shell-Skripte) zu verwenden, die immer identische Ausgaben erzeugen. Die Verwendung eines separaten Formats ermöglicht es Benutzern, diese Syntax weiterhin zu verwenden, ohne sich um die korrekte Implementierung von Fähigkeitsanzeigen kümmern oder versehentlich Aufrufer verwirren zu müssen, die nach Fähigkeiten fragen.
GIT
Teil der git[1] Suite