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.50.1 → 2.52.0 keine Änderungen
-
2.50.0
2025-06-16
- 2.43.1 → 2.49.1 keine Änderungen
-
2.43.0
2023-11-20
- 2.38.1 → 2.42.4 keine Änderungen
-
2.38.0
2022-10-02
BESCHREIBUNG
Dieses Dokument definiert Dinge, die verschiedenen Over-the-Wire-Protokollen und Dateiformaten in Git gemeinsam sind.
ABNF Notation
Die ABNF-Notation, wie sie in RFC 5234 beschrieben wird, wird innerhalb der Protokolldokumente verwendet, mit der folgenden Ersetzung von Kernregeln:
HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
Wir definieren auch die folgenden gemeinsamen Regeln:
NUL = %x00 zero-id = 40*"0" obj-id = 40*(HEXDIGIT) refname = "HEAD" refname /= "refs/" <see discussion below>
Ein Refname ist ein hierarchischer Oktett-String, der mit "refs/" beginnt und nicht gegen die Validierungsregeln des Befehls git-check-ref-format verstößt. Genauer gesagt:
-
Sie können Schrägstriche
/für hierarchische (Verzeichnis-) Gruppierung enthalten, aber keine schrägstrichgetrennte Komponente darf mit einem Punkt.beginnen. -
Sie müssen mindestens einen
/enthalten. Dies erzwingt die Anwesenheit einer Kategorie wieheads/,tags/usw., aber die eigentlichen Namen sind nicht eingeschränkt. -
Sie dürfen nirgendwo zwei aufeinanderfolgende Punkte
..enthalten. -
Sie dürfen keine ASCII-Steuerzeichen (d. h. Bytes mit Werten kleiner als \040 oder \177
DEL), Leerzeichen, Tilde~, Caret^, Doppelpunkt:, Fragezeichen ?, Sternchen*oder öffnende Klammer [ enthalten. -
Sie dürfen nicht mit einem Schrägstrich
/oder einem Punkt.enden. -
Sie dürfen nicht mit der Sequenz
.lockenden. -
Sie dürfen keine Sequenz
@{enthalten. -
Sie dürfen keine \\ enthalten.
pkt-line Format
Ein großer Teil (aber nicht alles) der Nutzdaten wird anhand von pkt-lines beschrieben.
Eine pkt-line ist ein binärer String variabler Länge. Die ersten vier Bytes der Zeile, die pkt-len, geben die Gesamtlänge der Zeile in Hexadezimal an. Die pkt-len umfasst die 4 Bytes, die zur Darstellung der Hexadezimalzahl der Länge verwendet werden.
Eine pkt-line KANN Binärdaten enthalten, daher MÜSSEN Implementierer sicherstellen, dass die Routinen zum Parsen/Formatieren von pkt-lines 8-Bit-sauber sind.
Eine nicht-binäre Zeile SOLLTE mit einem LF enden, das, falls vorhanden, in die Gesamtlänge AUFGENOMMEN werden MUSS. Empfänger MÜSSEN pkt-lines mit nicht-binären Daten gleich behandeln, unabhängig davon, ob sie den nachfolgenden LF enthalten oder nicht (entfernen Sie den LF, falls vorhanden, und beschweren Sie sich nicht, wenn er fehlt).
Die maximale Länge der Datenkomponente einer pkt-line beträgt 65516 Bytes. Implementierungen DÜRFEN keine pkt-line senden, deren Länge 65520 (65516 Bytes Nutzdaten + 4 Bytes Längendaten) überschreitet.
Implementierungen SOLLTEN keine leere pkt-line ("0004") senden.
Eine pkt-line mit einem Längenfeld von 0 ("0000"), genannt Flush-pkt, ist ein Sonderfall und MUSS anders behandelt werden als eine leere pkt-line ("0004").
pkt-line = data-pkt / flush-pkt data-pkt = pkt-len pkt-payload pkt-len = 4*(HEXDIG) pkt-payload = (pkt-len - 4)*(OCTET) flush-pkt = "0000"
Beispiele (als C-Style-Strings)
pkt-line actual value --------------------------------- "0006a\n" "a\n" "0005a" "a" "000bfoobar\n" "foobar\n" "0004" ""
GIT
Teil der git[1] Suite