Enterprise Server 3.20 ist derzeit als Release Candidate verfügbar.

Umgang mit Sonderzeichen in Branchnamen und Tag-Namen

Git ist sehr freizügig, wenn es darum geht, welche Zeichen in Branch- und Tagnamen erlaubt sind. Wenn du Git über eine Kommandozeilen-Schnittstelle verwendest, musst du eventuell Sonderzeichen entweder escapen oder in Anführungszeichen setzen.

In diesem Artikel

Informationen zu Branch- und Tagnamen

Die meisten Repositorys verwenden einfache Branchnamen, z. B. main oder update-icons. Tagnamen folgen in der Regel ebenfalls einem einfachen Format, z. B. einer Versionsnummer wie v1.2.3. Sowohl Branchnamen als auch Tagnamen können auch das Pfadtrennzeichen (/) für die Struktur verwenden, z.  B. area/item oder level-1/level-2/level-3. Abgesehen von einigen Ausnahmen (z. B. kein Schrägstrich am Anfang oder Ende eines Namens oder aufeinanderfolgende Schrägstriche im Namen) gibt es bei Git sehr wenige Einschränkungen bei der Verwendung von Branch- und Tagnamen. Weitere Informationen findest du unter git-check-ref-format in der Git-Dokumentation.

Warum Sie Sonderzeichen escapen müssen

Bei Verwendung einer CLI kann es vorkommen, dass ein Branch- oder Tagname Sonderzeichen enthält, die eine besondere Bedeutung für die Shellumgebung haben. Wenn du diese Zeichen sicher in einem Git-Befehl verwenden möchtest, musst du sie in Anführungs- oder Escapezeichen setzen. Andernfalls hat der Befehl möglicherweise eine unbeabsichtigte Wirkung.

Beispielsweise wird das Zeichen $ von vielen Shells verwendet, um auf eine Variable zu verweisen. Die meisten Shells würden einen gültigen Branchnamen wie hello-$USER als das Wort „Hallo“ gefolgt von einem Bindestrich gefolgt vom aktuellen Wert der USER-Variable interpretieren und nicht als die Literalzeichenfolge hello-$USER. Wenn ein Branchname das Zeichen $ enthält, muss die Shell davon abgehalten werden, es als Variablenverweis zu erweitern. Wenn ein Branchnamen ein Semikolon (;) enthält, wird dieses von den meisten Shells als Befehlstrennzeichen interpretiert, sodass es in Anführungszeichen gesetzt oder maskiert werden muss.

Wie man Sonderzeichen in Branch- und Tagnamen maskiert

Branch- und Tagnamen, die Sonderzeichen enthalten, können in den meisten Fällen in einfache Anführungszeichen gesetzt werden, z. B. 'hello-$USER'.

  • In der Bash-Shell wird durch Einschließen einer Zeichenfolge in einfache Anführungszeichen der Literalwert der eingeschlossenen Zeichen beibehalten.
  •         [Zsh](https://www.zsh.org/) verhält sich ähnlich wie Bash, doch ist dieses Verhalten über die Option `RC_QUOTES` konfigurierbar.

  •         [PowerShell](https://microsoft.com/powershell) behandelt Zeichen, die in einfache Anführungszeichen eingeschlossen sind, ebenfalls wörtlich.

Bei diesen Shells bildet der Fall, dass der Branch- oder Tagname selbst ein einfaches Anführungszeichen enthält, die wesentliche Ausnahme. In diesem Fall solltest du die offizielle Dokumentation für deine Shell zurate ziehen.

  •         [Bash-Dokumentation](https://www.gnu.org/software/bash/manual/)

  •         [Zsh-Dokumentation](https://zsh.sourceforge.io/Doc/)

  •         [Fish-Dokumentation](https://fishshell.com/docs/current/)

  •         [PowerShell-Dokumentation](https://docs.microsoft.com/en-gb/powershell/)

Benennen von Branches und Tags

Nach Möglichkeit sollten Branch- und Tagnamen keine Sonderzeichen enthalten, da diese maskiert werden müssten. Der folgende Standardzeichensatz ist für Branch- und Tagnamen sicher:

  • Das englische Alphabet (a bis z und A bis Z)
  • Zahlen (0 bis 9)
  • Eine begrenzte Reihe von Interpunktionszeichen:
  • Punkt (.)
  • Bindestrich (-)
  • Unterstrich (_)
  • Schrägstrich (/)

Um Verwirrung zu vermeiden, solltest du Branchnamen mit einem Buchstaben beginnen.

Einschränkungen für Namen in GitHub

In GitHub gelten beim Pushen von Branch- und Tagnamen einige wenige Einschränkungen. Diese Einschränkungen sind:

  • Namen dürfen Git-Objekt-IDs nicht ähneln (40 Zeichen enthalten; nur 0–9 und A–F), um Verwechslungen mit tatsächlichen Git-Objekt-IDs zu vermeiden.
  • Namen dürfen nicht mit refs/ beginnen, um Verwechslungen mit dem vollständigen Namen von Git-Verweisen zu vermeiden. Weitere Informationen zu Verweisen findest du in der Git-Dokumentation unter Git-Verweise.