Styleguide - GitHub Enterprise Server 3.8 Docs

Hinweis: Diese Richtlinien gelten speziell für die GitHub-Dokumentation. Allgemeine Stilfragen oder Anleitungen zu Themen, die hier nicht behandelt werden, findest du im Microsoft-Styleguide. Markup, das für den Quellinhalt in docs.github.com spezifisch ist, finden Sie unter „Verwenden von Markdown und Liquid in GitHub Docs“. Fragen zur Marke „GitHub“ findest du in unserem GitHub-Markenleitfaden.

Der GitHub Docs-Stil

Unser Styleguide ist auf Einfachheit ausgelegt. Die Anweisungen sollten einfach auf verschiedenste Szenarios angewendet werden können.
Entscheidungen sollten nicht danach gefällt werden, was gemäß Grammatikregeln oder dem Styleguide richtig oder falsch ist, sondern danach, was für unsere Benutzer*innen am besten ist. Wir sind flexibel und offen für Änderungen, doch auf Einheitlichkeit sollte geachtet werden.
Um den Styleguide erweitern zu können, wenn unser Team und die Dokumentationen wachsen, und um hochwertige, aussagekräftige Inhalte zu erstellen, die den Benutzer*innen weiterhelfen, konzentrieren wir uns die wesentlichen Szenarios, anstatt alle Stilfragen umfassend zu behandeln.
Konsistenz und grammatikalische Richtigkeit sind wichtig, aber nicht so wichtig wie Klarheit und Inhalt.
Wenn wir eine Stil- oder Strukturentscheidung treffen, berücksichtigen wir den Informationsfluss innerhalb der Inhaltseinheit und den Kontext der Informationen.
Wenn eine spezifische Frage zur Hilfedokumentation nicht im Styleguide behandelt wird, denken wir gemäß diesen Prinzipien darüber nach und treffen dann eine Entscheidung. Wenn eine Reviewerin nachfragt, sind wir darauf vorbereitet, die Entscheidung zu besprechen.

Überwachungsprotokollereignisse

Wir dokumentieren jedes der Ereignisse, die in den Überwachungsprotokollen für jeden Kontotyp angezeigt werden können: Benutzer, Organisation und Unternehmen.

Wenn du die Beschreibung für ein Überwachungsprotokollereignis formulierst, beschreibe das aufgetretene Event auf eine Weise, die auf alle Versionen zutrifft. Verwende dabei Präteritum und Passiv. Beginne den Satz nicht mit Ausdrücken, die bereits im Kontext des Artikels impliziert sind, z. B. „Wird ausgelöst“.

Verwenden: Die Sichtbarkeit eines Repositorys wurde geändert.
Verwenden: Die Geheimnisüberprüfung wurde für alle neuen Repositorys aktiviert.
Vermeiden: Eine Organisationsbesitzere hat die Zwei-Faktor-Authentifizierung für die Organisation deaktiviert.
Vermeiden: Wird ausgelöst, wenn Benutzer*innen aktualisieren, auf welche Repositorys ein Codespace zugreifen kann.

Aufrufe

Callouts heben wichtige Informationen hervor, die die Leser*innen wissen müssen. Wir haben die Formatierung und Farben für verschiedene Arten von Callouts in der gesamten Dokumentation standardisiert.

Verwende Callouts sparsam für besonders wichtige Informationen. Callouts sollten keine allgemeinen Informationen, Berechtigungen oder Voraussetzungen behandeln. Callouts dürfen maximal aus zwei Aufzählungspunkten bestehen.

Es gibt drei Arten von Callouts: Hinweise, Warnungen und Gefahrenhinweise.

Formatieren von Callouts

Jeder Callout beginnt mit Text, der auf die Art des Callouts hinweist (z. B. Warnung: ), um die Leser*innen zu informieren (unabhängig davon, ob sie visuell oder per Sprachausgabe auf die Website zugreifen) und dabei hilft, die Wichtigkeit und Notwendigkeit der Informationen im Callout einzuschätzen.

Hinweise werden in blauen {% note %}-Tags gerendert.

Hinweise enthalten nützliche Informationen oder Erinnerungen für die Benutzerinnen, die jedoch nicht befolgt werden müssen. Hinweise sind möglicherweise nicht für alle Benutzerinnen relevant oder notwendig.
Hinweisinhalten sollte **Note:** vorangestellt werden.

Warnungen und Gefahrenhinweise werden in roten {% warning %}-Tags gerendert.

Warnungen gelten für potenziell gefährliche Aktionen, die Benutzer*innen beachten sollten, bevor sie mit einer Aufgabe fortfahren. Dabei handelt es sich häufig um nicht optionale Schritte.
- Diesen Inhalten sollte **Warning:** vorangestellt werden.
Gefahrenhinweise gelten für gefährliche Aktionen, bei denen Benutzer*innen vor der Ausführung äußerste Vorsicht walten lassen sollten. Sie bergen häufig das Potenzial für Datenverlust oder andere schädliche Aktionen.
- Diesen Inhalten sollte **Danger:** vorangestellt werden.

Weitere Informationen zum Formatieren von Legenden finden Sie unter „Legenden“ in „Verwenden von Markdown und Liquid in GitHub Docs“.

Schaltflächen

Landing Pages und einige Artikel verfügen über Schaltflächen, die Personen zu relevanten Inhalten in anderen Artikeln oder auf anderen GitHub-Websites führen. Schaltflächen sollten verwendet werden, wenn jemand zu einer anderen Seite navigieren muss, um die beschriebene Aufgabe abzuschließen. Beispielsweise verfügt Eine Testversion von GitHub Enterprise einrichten über eine Schaltfläche, die Personen zur Anmeldeseite der Testversion bringt, da dies der nächste Schritt beim Einrichten einer Testversion ist. Die Landing Page Migrationsdokumentation verwendet eine Schaltfläche, um Personen zu dem Artikel zu leiten, den die meisten lesen müssen, um mit einer Migration zu beginnen.

Wenn eine Schaltfläche dazu anregt, von der GitHub Docs-Website weg zu navigieren, befolge die Richtlinien für CTA-Schaltflächen (Call to Action). Wenn Sie einen anderen Schaltflächentyp auf einer Zielseite oder einem Artikel einschließen möchten, müssen Sie die Genehmigung des GitHub Docs-Teams erhalten.

CTA-Schaltflächen

CTA-Schaltflächen heben einen Link hervor, zu dem Leserinnen nach dem Lesen eines Artikels oder während der in einem Artikel beschriebenen Aufgabe navigieren sollen. CTA-Schaltflächen sollten die Leserinnen nur zu GitHub-eigenen Domänen führen. Die CTA-Schaltfläche „GitHub Copilot ausprobieren“ unter „Erste Schritte mit GitHub Copilot“ verweist beispielsweise auf das GitHub Copilot-Einstellungsmenü auf GitHub.com.

Füge CTA-Schaltflächen nur ein, wenn Benutzerinnen davon profitieren. Verwende CTA-Schaltflächen nicht, um Werbung für GitHub-Features oder -Produkte zu machen. Im obigen Beispiel muss jemand, der GitHub Copilot ausprobieren möchte, zum Einstellungsmenü von Copilot navigieren und dies wahrscheinlich nach dem Lesen des Artikels tun möchten. Wenn jemand aber beispielsweise Copilot beim Schreiben des Codes verwendet, für den der- oder diejenige dann einen Pull Request erstellt, würden wir unter Erstellen eines Pull Requests keine Schaltfläche mit dem Text „Jetzt GitHub Copilot ausprobieren“ hinzufügen, da Copilot nicht mit dem Bedarf des Benutzers oder der Benutzerin zusammenhängt, einen Pull Request zu erstellen. Die meisten Personen erstellen Pull Requests, ohne Copilot zu verwenden. Personen, die Artikel über die ersten Schritte mit Copilot lesen, sind jedoch wahrscheinlich daran interessiert, Copilot auszuprobieren, wenn sie das Tool nicht bereits verwenden. Daher fügen wir die CTA-Schaltfläche hinzu, um den Leserinnen zu helfen, zum gewünschten Ziel zu gelangen.

Erstelle CTA-Schaltflächen im folgendem Format:

<a href="https://github.com/DESTINATION/URL" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Try PRODUCT NAME</span> {% octicon "link-external" height:16 %}</a>

Code

Codeblöcke

Begrenze Zeilen in Codebeispielen auf etwa 60 Zeichen, um zu vermeiden, dass die Leser*innen horizontal im Codeblock scrollen müssen. Füge erklärenden Text vor dem Codeblock ein, anstatt Kommentare innerhalb des Codeblocks zu verwenden. Weitere Informationen zur Syntax der Codesuche finden Sie unter Verwenden von Markdown und Liquid in GitHub Docs.

Innerhalb von Codeblöcken:

Gib die Sprache des Beispiels nach dem ersten Codefence an. Eine Liste aller unterstützten Sprachen findest du unter Codesprachen im Repository github/docs.
Verwenden Sie HTML nicht zum Formatieren oder Markup eines Codeblocks.
Formatieren Sie alle Platzhalter, die personen durch ihre eigenen Werte in allen Kapitälchen ersetzen müssen.
- Verwenden Sie git checkout -b BRANCH-NAME
- Vermeiden Sie: git checkout -b <branch-name>
Verwende keine Eingabeaufforderungen wie $ vor dem Befehl selbst. Diese Eingabeaufforderungen machen es für Leser schwierig, den Befehl zu kopieren und einzufügen.
- Wenn du einen Befehl und die Ausgabe des Befehls anzeigst, kommentiere die Ausgabe im Beispiel.
- Verwendung:
```
command
# output
```
- Vermeiden:
```
$ command
output
```
Wenn dein Codebeispiel { oder } enthält, die gerendert werden sollen, schließe den Abschnitt in {% raw %} {% endraw %} ein, um die Liquid-Verarbeitung für diesen Abschnitt zu deaktivieren.
- Verwenden:
```
GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
```
- Vermeiden:
```
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```
Wenn dein Codebeispiel Inhalte aufweist, die geparst werden sollen, umschließe diesen Abschnitt in <pre>- und </pre>-Tags, um ihn zu parsen, anstatt den Inhalt im Abschnitt zu escapen.

Befehle

Verwende Inlinecodeblöcke für kurze Befehlsnamen.

Verwenden: Um den Status eines ausgeführten Clusters zu überprüfen, verwende den Befehl ghe-cluster-status.

Verwende Befehlsblöcke für längere oder komplexere Befehle.

Verwenden: Aktiviere den Wartungsmodus gemäß deinem geplanten Fenster, indem du eine Verbindung mit der Verwaltungsshell eines beliebigen Serverknotens herstellst und den folgenden Befehl ausführst:
```
ghe-cluster-maintenance -s
```

Nimm keine Eingabeaufforderungen wie $ auf. Vermeide Inlinelinks in Befehlsnamen.

Ausgaben

Wenn du die Ausgabe eines Befehls anzeigst, kommentiere die Ausgabe im Beispiel, damit Benutzer den Befehl kopieren und einfügen und ohne Änderung ausführen können.

Verwendung:
```
git lfs install
# Git LFS initialized.
```

Vermeiden:

$ git lfs install
> Git LFS initialized.

Beispiele

Wenn Codebeispiele auf eine größere Datei verweisen, zeige den relevanten Abschnitt der Datei, damit Leser*innen verstehen, wie sie ihren eigenen Code im Kontext bearbeiten können.

Verwendung:

on:
  schedule:
    - cron:  "40 19 * * *"

Vermeiden:

schedule:
  - cron:  "40 19 * * *"

Dateinamen und Verzeichnisnamen

Verwenden Sie Backticks, um Verweise auf Dateinamen und Verzeichnisnamen in einer Festbreitenschriftart zu formatieren. Wenn ein Dateityp im Allgemeinen einer bestimmten Großschreibungskonvention folgt, z. B. nur Großbuchstaben für README-Dateien, wende die bestehende Konvention an.

Verwenden: Füge in deiner README.md-Datei Informationen zu deinem Repository hinzu.
Verwenden: Erstelle die example-workflow.yml-Datei in deinem Verzeichnis .github/workflows/.
Vermeiden: Erstelle die example-workflow.yml-Datei im Verzeichnis .github/workflows/ .
Vermeiden: Lösche die Datei example.js.

Indentation

Verwende in YAML-Beispielen, z. B. Aktionen und Workflowdateien, zwei Leerzeichen, um Zeilen in geschachtelten Listen und Blocksequenzen einzurücken.

Verwendung:

    steps:
      - uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: ${{ matrix.python }}

Informationen zum Einrücken von wiederverwendbaren Zeichenfolgen findest du unter data/reusables/README.md.

Geplante Workflows

Workflowausführungen werden verzögert, wenn zu viele Workflows gleichzeitig ausgeführt werden. Da viele Benutzer*innen Code aus der GitHub Docs kopieren, sollten wir Beispiele verwenden, die nicht zu überlasteten Zeiten ausgeführt werden.

Verwende keine Beispiele, die zur vollen Stunde ausgeführt werden, da dies die am stärksten überlasteten Zeiten sind.
Verwende keine Beispiele, die häufiger als nötig ausgeführt werden. Statt das Beispiel alle fünf Minuten auszuführen, solltest du darüber nachdenken, ob es sinnvoller ist, es alle 30 Minuten auszuführen.
Verwende für jedes Beispiel eine andere Uhrzeit.

Hervorhebung

Verwende Kursivschrift, um Wörter oder Teile eines Satzes hervorzuheben. Verwende Hervorhebungen sparsam für Terminologie oder Kontext, der bekannt sein muss, um die aktuelle Aufgabe erfolgreich abzuschließen. Verwende keine Kursivschrift, um Wörter hervorzuheben, für die andere Formatierungen angewendet werden, z. B. Großbuchstaben für Platzhaltertext oder Fettformatierung für Benutzeroberflächenelemente.

Verwenden: fine-grained personal access token haben gegenüber personal access tokens einige Sicherheitsvorteile.
Verwenden: Wähle für andere Pakettypen als Container rechts neben der Paketversion die Option Löschen aus.
Vermeiden: Füge neben Titel eine beschreibende Bezeichnung für deinen neuen Schlüssel hinzu.

Fehlermeldungen

Wenn Sie den Text einer Fehlermeldung aus einem GitHub-Produkt oder einer Schnittstelle in einen Artikel einschließen, müssen Sie den Text entsprechend der Schnittstelle formatieren, auf der die Nachricht angezeigt wird.

Wenn die Meldung in der Weboberfläche von GitHub oder in einer grafischen Client-App wie GitHub Desktop oder GitHub Mobile angezeigt wird, behandeln Sie die Nachricht wie andere Texte auf der Benutzeroberfläche. Weitere Informationen finden Sie unter „Benutzeroberflächentext“.
Wenn die Nachricht in einer Befehlszeilenschnittstelle, einer Protokollausgabe oder einer Antwort von einer API angezeigt wird, müssen Sie den Text genau reproduzieren und Backticks verwenden, um die Nachricht mit einer Festbreitenschriftart zu formatieren.

Fußnoten

Vermeide nach Möglichkeit die Verwendung von Fußnoten. Überlege stattdessen, ob du einen Callout verwenden oder die Informationen auf andere Weise darstellen kannst. Sieh dir einige Beispiele für Alternativen zu Fußnoten auf NICE.org.uk an.

Wenn Sie Fußnoten verwenden müssen, verwenden Sie Markdown-native Fußnoten ([^1]). Fußnotenmarkierungen werden mit dem Fußnotenverweis verknüpft, der am unteren Rand der Seite mit einer Rückverlinkung zur Markierung aufgeführt wird.

Beachten Sie, dass Fußnoten unabhängig vom verwendeten Bezeichner (Buchstaben, Wörter) als sequenzielle Zahlen gerendert werden.

	Mona	Ursula	Paul	Davy Jones¹
Lieblingsvertreib	Shippingcode	Irreführende Meerjungfrauen²	Vorhersagen von Sportarten	Gespenstische Seeleute
Nutzung von Macht für gute Zwecke	Ja	Keine	Ja	No

| | Mona | Ursula | Paul | Davy Jones[^1] |
|---|---|---|---|---|
|Favorite pastime| Shipping code | Tricking mermaids[^2] | Predicting sports | Haunting seafarers |
|Uses powers for good| Yes | No | Yes | No |
[^1]: Not to be confused with Davy Jones of The Monkees
[^2]: Also humans

Headers

Überschriften müssen den nachfolgenden Inhalt angemessen beschreiben. Kopfzeilen können entweder den Richtlinien zum Schreiben von Titeln folgen oder als Fragen formuliert werden. Ersten Buchstaben in den Headern großschreiben. Jede Überschrift auf einer Seite muss einmalig sein.

Wenn ein Artikel Überschriften enthält, muss die erste eine H2-Überschrift sein. Du kannst H3- und H4-Ebenenheader verwenden, um Inhalte in verwandte Gruppen weiter zu organisieren, aber du kannst keine Kopfzeilenebenen überspringen. Zwischen einer Überschrift und einer Zwischenüberschrift muss Text vorhanden sein, z. B. eine Einleitung.

Verwendung:

## HEADER (H2)
TEXT

### SUBHEADER (H3)
TEXT

#### SUBHEADER (H4)
TEXT

Vermeiden:
```
## HEADER (H2)

#### SUBHEADER (H4)
```

Wenn du auf Überschriften verweist, umschließe den Namen der Überschrift mit Anführungszeichen.

Verwenden: Zeige unter „Benutzerlizenzen“ alle deine Lizenzen an.

Weitere Informationen finden Sie unter Inhalt eines GitHub-Docs-Artikels.

Bilder

Wir verwenden statische Bilder, einschließlich Screenshots und Diagrammen in der gesamten Dokumentation, um Textinformationen zu ergänzen.

Verwende keine animierten GIFs in der Dokumentation.

Alternativer Text

Jedes Bild muss Alternativtext enthalten, der ein Textäquivalent der visuellen Informationen bereitstellt.

Drücke die Kernidee oder die Bedeutung des Bilds aus, anstatt es wörtlich zu beschreiben.
Verwende 40 bis 150 Zeichen.
Ende mit einem Satzzeichen. Es sollte in der Regel ein Punkt sein, es sei denn, der Alternativtext beschreibt ein Bild mit Text, der mit einem anderen Satzzeichen endet, z. B. einem Fragezeichen oder Ausrufezeichen.
Beginnen Sie nicht mit „Bild ...“ oder „Grafik ...“. Sprachausgaben sagen das automatisch.
Beginnen Sie mit der Art der Grafik: „Screenshot von ...“ oder „Diagramm, das zeigt ...“.
Wende die Standardsprache an, die zum Beschreiben von Benutzeroberflächenelementen im Artikeltext verwendet wird.
Schließe Titel mit mehreren Wörtern, z. B. Namen von Menüelementen, in doppelte Anführungszeichen („“) ein.
Wenn ein Bereich des Bilds visuell hervorgehoben ist, beschreibe diesen. Dies ermöglicht es Benutzer*innen der Sprachausgabe, zu verstehen und anderen zu beschreiben, wonach sie aus Sicht der visuellen Sprache suchen müssen.

Alternativtext für Screenshots

Alternativtext enthält eine kurze Beschreibung des Inhalts eines Screenshots für Personen, die ihn nicht sehen können.

Alternativtext muss nur die relevantesten Elemente eines Bilds enthalten, nicht jedes Detail.
Alternativtext soll keine Anweisungen für die Verwendung der GitHub-Benutzeroberfläche bereitstellen. Diese sollten in den Artikeltext aufgenommen werden.

Format

Screenshot von Product name + UI element. UI element + state of the element/controls und keyboard shortcut XYZ sind dunkelorange umrandet.

Verwende für Product name den GitHub-Produkt- oder -Featurenamen, z. B. GitHub Actions oder GitHub, statt nur GitHub.
Verwende eine Variable für das Wort GitHub wie in der laufenden Version: {% data variables.product.prodname_dotcom %}.
Bezeichne Benutzeroberflächenelemente genau wie in der schriftlichen Dokumentation.
Verändere die Wortreihenfolge, wenn dies zur Übersichtlichkeit erforderlich ist.
- Schreiben Sie z. B. „Screenshot des Menüs ‚Debuggen‘ in Visual Studio Code …“ anstatt „Screenshot des Visual Studio Code-Debuggen-Menüs …“, um mehrere aneinandergereihte Substantive zu vermeiden.

Beispiele

Screenshot: GitHub-Committers nach Repositorytabelle. Das horizontale Kebab-Symbol und die Schaltfläche „CSV-Bericht herunterladen“ sind dunkelorange umrandet.

Screenshot der Dateioptionen in einem GitHub-Repository. Eine Schaltfläche mit einem Pfeil, der auf ein Dropdownmenü mit der Bezeichnung „Code“ hinweist, ist dunkelorange umrandet.

Alternativtext für Diagramme

Erkläre die Informationen, die im Diagramm auf der Seite vermittelt werden.

Verwende Alternativtext, um die Kernidee des Bilds auszudrücken, ohne den Webseitentext zu duplizieren.

Beispiel

Diagramm eines fünfstufigen Prozesses, mit dem ein GitHub Actions-Runner automatisch benannten Klassen von Runnern hinzugefügt wird und dann von bestimmten Aufträgen angefordert werden kann.

Weitere Informationen sind in der Erklärung zu diesem Diagramm in der Dokumentation zu Aktionen zu finden.

Alternativtext für Bilder von Befehlszeilenschnittstellen

Verwende keine Screenshots von Befehlszeilenschnittstellen, um Befehle und deren Ausgabe darzustellen. Gib stattdessen direkt die Befehle an, die Leser*innen verwenden sollen. Weitere Informationen findest du im Abschnitt Befehle des Styleguides.

Wenn du einen Screenshot einer Befehlszeilenschnittstelle verwendest, um Elemente der Benutzeroberfläche darzustellen, befolge die Standardanweisungen für Alternativtext von Screenshots.

Dateinamen für Bilder

Bilddateien sollten aussagekräftig benannt werden: Geben Sie den Namen, die Aktion und das Benutzeroberflächenelement im Dateinamen an. Verwende die Produktsprache. Verwende die Kebab-Case-Schreibweise. Verwenden Sie keine Liquid-Bedingungen in Dateinamen. Wenn Sie ein Bild ersetzen, verwenden Sie den genauen Dateinamen.

Verwenden Sie: data-pack-purchase-button.png
Vermeiden: purchase_button.png
Vermeiden: purchase-button-for-admins.png

Screenshots

Informationen zum Erstellen und zur Versionsverwaltung von Bildern findest du unter Erstellen und Aktualisieren von Screenshots.

Diagramme

Weitere Informationen zum Erstellen von Diagrammen finden Sie unter „Erstellen von Diagrammen für GitHub Docs“.

Inklusive Sprache

Als Heimat der größten Entwicklercommunity der Welt setzt sich GitHub dafür ein, Vielfalt und Inklusion in allen Bereichen unserer Aktivitäten zu fördern. Unsere gesamte Dokumentation ist inklusiv und respektvoll gegenüber unserem Publikum, das aus Menschen mit ganz unterschiedlichen Hintergründen aus aller Welt besteht. In unserer Dokumentation verwenden wir nur Wörter, die inklusiv, nicht rassistisch und nicht ableistisch sind.

Einzelne Wörter können unbedeutend wirken, aber zusammen können sie Gemeinschaft, Zugehörigkeit und Gleichheit schaffen. Sei einfühlsam bei allen Wort- und Stilentscheidungen. Achte darauf, Personen und Communitys korrekt zu bezeichnen.

Zweck	Vermeiden
Positivliste	Whitelist
Verweigerungsliste	Blacklist
Standard-/Mainbranch	Masterbranch

Ressourcen zu inklusiver Sprache

Der Microsoft-Styleguide enthält Ressourcen zu unvoreingenommener Kommunikation, nicht ableistischen Begriffen und leicht verständlichem Schreiben:

Weitere Ressourcen zu inklusiver und nicht ableistischer Sprache und inklusivem und nicht ableistischem Stil:

18F-Inhaltsleitfaden zu inklusiver Sprache
Styleguide von MailChimp:
- Schreiben über Personen
- Schreiben für Barrierefreiheit
Richtlinien zur Lesbarkeit
Styleguide für bewusste Sprache

Tastenkombinationen

Befolge bei der Angabe von Tastenkombinationen den Microsoft-Styleguide, mit Ausnahme der folgenden Unterschiede:

Verwende das HTML-Tag <kbd> für jede einzelne Taste.
- Verwenden: <kbd>Command</kbd>+<kbd>B</kbd>
- Vermeiden: Command+B
Verwende ganze Wörter anstelle von Symbolen für Apple-Zusatztasten.
- Verwenden: Command
- Vermeiden: ⌘
Verwende Symbole für Tasten mit Sonderzeichen, keine ganzen Wörter.
- Verwenden: ., , und →
- Vermeiden: Period, Comma und Right arrow

Hervorhebungen

Im Folgenden findest du einige Hervorhebungen für die Darstellung von Tastenkombinationen in unserer Dokumentation:

Die grundlegende Syntax besteht darin, Tastenkombinationen mit + zwischen den Tasten und ohne Leerzeichen anzugeben.
- Verwenden: <kbd>Command</kbd>+<kbd>B</kbd>, wird als Command+B gerendert
- Vermeiden: <kbd>Command</kbd> + <kbd>B</kbd> oder <kbd>Command + B</kbd>, wird als Command + B oder Command + B gerendert
Buchstabentasten werden für allgemeine Verweise und Tastenkombinationen immer groß geschrieben.
- Verwenden: BEFEHL+B
- Vermeiden: BEFEHL+b
Verwende die richtigen Zusatztasten für jedes Betriebssystem.

Hinweis: Unter Windows und Linux wird STRG abgekürzt, während es unter Mac ausgeschrieben ist: Control.
- Für Windows und Linux:
  - Verwenden: STRG, ALT
  - Vermeiden: Steuerung
- Für Mac:
  - Verwenden: Command, Option, Control
  - Vermeiden: Cmd, ⌘, Opt, ⌥, Ctrl, ⌃
Verwechsle Tastenkombinationen nicht mit Tastenabfolgen.
- BEFEHL+B bedeutet, dass Benutzer*innen die Taste BEFEHL gedrückt halten und dann B-Taste drücken sollen.
- G I bedeutet, dass Benutzer*innen zuerst die G-Taste und dann die I-Taste drücken sollen.
Wenn du eine Tastenkombination für mehrere Betriebssysteme beschreibst, gib das Betriebssystem in Klammern hinter der Tastenkombination an. Beschreibe zuerst die Mac-Tastenkombination, dann die Tastenkombination für Windows/Linux.
- Verwenden: <kbd>Command</kbd>+<kbd>B</kbd> (Mac) or <kbd>Ctrl</kbd>+<kbd>B</kbd> (Windows/Linux), dargestellt als:
  
  BEFEHL+B (Mac) oder STRG+B (Windows/Linux)
- Vermeiden: <kbd>Ctrl</kbd>+<kbd>B</kbd> or <kbd>Command</kbd>+<kbd>B</kbd>, dargestellt als:
  
  STRG+B oder BEFEHL+B

Lizenzierte Inhalte

GitHub Docs ist unter einer CC-BY-Lizenz lizenziert. Wenn du lizenzierte Inhalte in einem Artikel wiederverwendest oder änderst, musst du sicherstellen, dass die Lizenz anwendbar und ordnungsgemäß genannt ist.

Erstelle keine wiederverwendbaren Zeichenfolgen für Lizenznennungen. Wir müssen genau die Lizenz verwenden, unter der ein Projekt lizenziert ist, daher müssen alle Nennungen speziell für die Artikel verfasst werden, in denen sie erscheinen.

Wenn du dir bezüglich der Rechtmäßigkeit der Wiederverwendung von Inhalten nicht sicher bist, wenden dich an das Rechtsteam. Wenn du Inhalte mit einer Lizenz hinzufügst, die unten nicht aufgeführt ist, muss eine rechtliche Prüfung erfolgen, bevor du den Inhalt veröffentlichen kannst.

Lizenznennung bei MIT-lizenzierten Inhalten

Wenn wir Inhalte unter einer MIT-Lizenz wiederverwenden oder ändern, müssen wir die MIT-Lizenz dort nennen, wo der Inhalt erscheint.

Am Ende des Artikels mit MIT-lizenzierten Inhalten:

Erstelle eine Überschrift mit dem Titel Legal notice.
Gib an, woher der Inhalt stammt und dass er unter der MIT-Lizenz lizenziert ist. Füge einen Links zum Projekt ein.
Füge den vollständigen Text der MIT-Lizenz aus dem Projekt ein, das du in einem Codeblock nennst.

Beispiel für eine MIT-Lizenznennung

Dieser Text ist nur ein Beispiel. Verwende immer den Lizenztext aus dem Projekt, auf das du dich beziehst.

## Legal notice

Portions have been adapted from [PROJECT](/LINK/TO/PROJECT) under the MIT license:

```
MIT License

Copyright YEAR COPYRIGHT-HOLDER

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
```

Zeilenumbrüche

Für Nur-Text werden Zeilenumbrüche verwendet, um Absätze in der Quelle (zwei aufeinanderfolgende Zeilenumbrüche) zu trennen, anstatt visuellen Abstand in der Quelle zu erzeugen. Vermeide nicht benötigte Zeilenumbrüche, insbesondere in Listen.

Verknüpfungen

Die Links müssen konsistent, für möglichst viele Personen barrierefrei, übersetzbar und eindeutig sein. Personen müssen wissen, wohin ein Link führt und wie er sich auf das bezieht, was sie erreichen möchten.

Bevor Sie einen Link hinzufügen, sollten Sie entscheiden, ob jemand den Link besuchen muss, um den Inhalt zu verstehen. Wenn der Link nicht erforderlich ist, sollten Sie ihn entfernen oder am Ende des Artikels als weiterführende Information einschließen.

Sie können Links auch nur mit dem Begriff „siehe“ einleiten, wenn aus dem Kontext klar hervorgeht, wofür der Link gedacht ist. Wenn der Kontext nicht eindeutig ist, verwenden Sie einen Ausdruck oder einen Satz, um den Link einzuführen, z. B. „Weitere Informationen finden Sie unter“ oder „Weitere Informationen zu X finden Sie unter Y“.

Verwenden Sie den Titel des Dokumentationsartikels oder der externen Webseite als Linktext. Verwenden Sie für alle Links, die auf einen anderen Artikel auf der GitHub Docs-Seite verweisen, das spezielle Schlüsselwort AUTOTITLE. Weitere Informationen finden Sie in der Referenz zu Markup für Inhalte.

Verwenden Sie keine Inline-Links, bei denen Wörter innerhalb des Satzes ohne zusätzliche Wörter verlinkt werden, um anzuzeigen, dass der Satz einen Link enthält. Das kann schwierig zu übersetzen und noch schwieriger zu lesen sein.

Verwendung: OAuth2 tokens can be acquired programmatically for applications that are not websites. For more information, see "[AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app)" and "[AUTOTITLE](/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps)."
Vermeiden Sie: Read [more about OAuth2](/apps/building-integrations/setting-up-and-registering-oauth-apps/). Note that OAuth2 tokens can be [acquired programmatically](/enterprise-server@2.22/rest/reference/oauth-authorizations/#create-a-new-authorization), for applications that are not websites.

Anwendungsbeispiele:

Für Links zu anderen Seiten: See "[AUTOTITLE](/PATH/TO/PAGE)."
Für Links zu Abschnitten auf anderen Seiten: For more information, see "[AUTOTITLE](/PATH/TO/PAGE#SECTION-LINK)."
Für Links zu einer Seite mit ausgewähltem Tool: For more information, see the TOOLNAME documentation in "[AUTOTITLE](/PATH/TO/PAGE?tool=TOOLNAME)."

Links zu Abschnitten auf derselben Seite funktionieren nicht mit AUTOTITLE. Gib stattdessen den vollständigen Überschriftentext ein: For more information, see "[HEADER-TITLE](#SECTION-LINK)."

Geben Sie für Links zu einer externen Seite (darunter verstehen wir jede Website, die nicht von Dependabot verwaltet wird) den vollständigen Seitentitel und die Zielwebsite ein.

Verwenden Sie: See [PAGE-TITLE](https://some-docs.com/PATH/TO/PAGE) in the XYZ documentation.
Vermeiden: See [PAGE-TITLE](https://some-docs.com/PATH/TO/PAGE).
Vermeiden: See [the OTHER WEBSITE](https://some-docs.com/PATH/TO/PAGE).

Füge keine Anführungszeichen in einen Link ein.

Einige Best Practices für die Verwendung von Links:

Links sollten aussagekräftig sein und nützlich sein, also verwende sie mit Bedacht.
Verschiebe Links, die hilfreich, aber nicht notwendig sind, in den Abschnitt „Weitere Ressourcen“ eines Artikels.
Wiederhole einen Link nicht mehrmals im selben Artikel oder unter derselben H2-Überschrift.
Schließe den Abfrageparameter apiVersion nicht in REST-Links ein, es sei denn, du musst einen Link zu einer bestimmten Kalenderversion der REST-Dokumentation angeben. (Das sollte selten vorkommen.)

Links zwischen Versionen

Manchmal müssen Sie von einer Version von GitHub Docs zu einer anderen verlinken. Wenn du einen Link zu einer anderen Version derselben Seite erstellen möchtest, solltest du die currentArticle-Eigenschaft verwenden.

Beispielsweise kann die Free-, Pro- und Team-Version von Verwalten der Veröffentlichung von GitHub Pages-Websites für deine Organisation wie folgt mit der GitHub Enterprise Cloud-Version desselben Artikels verlinkt werden:

You can choose to allow or disallow the publication of GitHub Pages sites.

Organizations that use {% data variables.product.prodname_ghe_cloud %} can choose to allow publicly published sites, privately published sites, both, or neither. For more information, see [the {% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/{{ currentArticle }}).

Verwende das folgende Format, um einen Link zu einem anderen Artikel in einer anderen Version zu erstellen:

For more information, see "[ARTICLE TITLE](/)" in the VERSION documentation.

Verwende das folgende Format, um einen Link zum selben Artikel in einer anderen Version zu erstellen:

For more information, see [the VERSION documentation](/VERSION/{{ currentArticle }}).

Um einen Link zu einer bestimmten Version zu erstellen, musst du die Version in den Pfad einschließen (z. B. /enterprise-cloud@latest/{{ currentArticle }}).

Links zu bestimmten Abschnitten von Artikeln

Wenn wir mit bestimmten Abschnitten von Artikeln verlinken, möchten wir sicherstellen, dass der Link aussagekräftig genug ist, damit die Leser*innen wissen, dass sie sich nach dem Auswählen eines Links an der richtigen Stelle befinden.

Verwende das folgende Format, um einen Link zu einer bestimmten Überschrift im selben Artikel zu erstellen:

For more information, see "[HEADER TITLE](#HEADER-TITLE)."

Verwende das folgende Format, um einen Link zu einer bestimmten Überschrift in einem anderen Artikel zu erstellen:

For more information, see "[AUTOTITLE](PATH-TO-ARTICLE#HEADER-TITLE)."

Verwende das folgende Format, um einen Link zu zwei oder mehr bestimmten Überschriften in einem anderen Artikel zu erstellen:

For more information, see "[HEADER-TITLE-1](PATH-TO-ARTICLE#SECTION-LINK-1)" and "[HEADER-TITLE-2](PATH-TO-ARTICLE#SECTION-LINK-2)" in "ARTICLE-TITLE."

Links zu einem bestimmten Tool

Wenn wir Inhalte verlinken und ein bestimmtes Tool ausgewählt ist, möchten wir sicherstellen, dass die Leser*innen wissen, dass die dargestellten Inhalte für das Tool relevant sind, auch wenn die Registerkarten zum Wechseln des Tools im Artikel gerade nicht sichtbar sind.

For more information, see the TOOLNAME documentation in "[ARTICLE TITLE](/PATH/TO/ARTICLE?tool=TOOLNAME)."

Links zu Lernpfaden

Verwende dieses Format, um einen Link zu einem Lernpfad zu erstellen.

For more information, follow the "[LEARNING PATH TITLE](/)" learning path.

Links zu externen Ressourcen

Wählen Sie beim Verlinken mit einer externen Website die nützlichste Ressource für den Kontext des Links aus. Sie können einen Link zu einer ganzen Website erstellen, wenn es sich um einen allgemeinen Verweis handelt, oder auf eine bestimmte Seite, wenn diese hilfreicher wäre.

Es ist nicht erforderlich, auf die Website eines externen Produkts zu verlinken, wenn wir ein externes Produkt erwähnen.

Hinzufügen von Ankern zum Beibehalten von Links

Wenn Sie wissen, dass es Links zu einem bestimmten Abschnitt eines Artikels gibt, können Sie dem Abschnitt einen Anker hinzufügen, um den Link beizubehalten. Wenn beispielsweise eine externe Ressource mit einem bestimmten Abschnitt eines Artikels verknüpft ist, können Sie einen Anker hinzufügen, sodass der Link zum richtigen Abschnitt führt, auch wenn sich der Abschnittstitel ändert.

Verwenden Sie dieses Format für Verknüpfungsanker. Der Ankername sollte der Abschnittsname sein, der beibehalten wird. Verwenden Sie einen HTML-Kommentar, um zu erläutern, warum Sie den Anker hinzufügen.

<a name="SECTION-TITLE-THAT-MIGHT-CHANGE"></a>

Listen

Schreibe den ersten Buchstabens in jeder Zeile einer Liste groß. Verwende nur Punkte am Ende der Zeilen in einer Liste, wenn die Zeile einen vollständigen Satz enthält.

Verwende beim Schreiben einer Liste von Elementen, die aus primärem und sekundärem Text bestehen, z. B. einem term und dessen Definition, einen Doppelpunkt als Trennzeichen. Der sekundäre Text sollte so groß geschrieben werden, als wäre er der Anfang der Zeile. Zum Beispiel:

foo: Etwas, das bar bereitstellt
bar: Etwas, das von foo bereitgestellt wird

Formatieren von nicht sortierten Listen:

Wenn die Reihenfolge der Elemente in der Liste nicht wichtig ist, ordne die Listenelemente alphabetisch an.
Wenn die Reihenfolge wichtig ist, ordne die Liste nach der Bedeutung für die Leser*innen an (z. B. von der größten Zielgruppe und der Anwendbarkeit bis zu einer spezialisierteren Zielgruppe).

Vermeiden Sie beim Einführen einer Liste kurze, unspezifische Sätze mit Ausdrücken wie „die folgenden“ oder „diese“, die ohne Kontext schwer zu lokalisieren sind. Erstellen Sie stattdessen einen beschreibenden Satz, der den Betreff der Liste deutlich vermittelt, wobei die Liste aber skaliert oder geändert werden kann, ohne dass die Beschreibung aktualisiert werden muss.

Verwendung:

Eine Einführung in GitHub finden Sie in den folgenden Artikeln:
Die SMS-Authentifizierung wird in diesen Ländern unterstützt:

Vermeiden:

Es gibt mehrere Artikel, die eine Einführung in GitHub bieten. Siehe Folgendes:
Die SMS-Authentifizierung wird in 50 Ländern unterstützt: Dazu gehören:

Platzhalter

Formatieren Sie Platzhaltertext in Großbuchstaben. Wenn ein Platzhalter mehrere Wörter ist, verbinden Sie die Wörter mit Bindestrichen (Kebab-Großbuchstabe). Wenn Sie einen Platzhalter verwenden, erläutern Sie, durch was jemand ihn ersetzen könnte. Auf diese Weise können Benutzer Beispiele an ihre Bedürfnisse anpassen und Platzhalter für Personen identifizieren, die Hilfstechnologien verwenden.

Verwendung:

Ersetzen Sie im folgenden Beispiel IHR-REPOSITORY durch den Namen Ihres Repositorys. git init YOUR-REPOSITORY
Klicken Sie auf ADD USERNAME (BENUTZERNAME HINZUFÜGEN). Dabei ist USERNAME der Benutzername der Person, die Sie hinzufügen möchten.

Vermeiden:

git init your repository
git init <your-repository>
Klicken Sie auf Benutzername hinzufügen.

Schritte in Abläufen

Abläufe veranschaulichen den Leserinnen eine Reihe aufeinanderfolgender Schritte, die zum Ausüben einer Aufgabe erfolgen müssen. Verwenden für Abläufe immer nummerierte Listen. Vermittle den Leserinnen zuvor alle Voraussetzungen oder konzeptionellen Informationen, die sie für die Aufgabe benötigen, anstatt sie in einen bestimmten Schritt zu integrieren.

Jeder Schritt muss eine Aktion enthalten. Du kannst auch angeben, ob ein Schritt optional ist, den Grund oder das Ergebnis des Schritts erklären und den Leser*innen bei der Orientierung helfen, indem du erklärst, wo die Aktion stattfinden muss, bevor die Anleitung folgt.

Verwende eine einheitliche Reihenfolge, um die Informationen in jedem Schritt anzugeben.

Wenn der Schritt optional ist, gib diese Information zuerst an.
Wenn es für das Verständnis oder die Betonung der Auswirkungen einer schädlichen oder verwirrenden Aktion erforderlich ist, gib den Grund für den Schritt oder dessen Resultat an.
Beschreiben, wo die Benutzer*innen die Aktion durchführen müssen.
Action (Aktion).

Verwenden: Optional kannst du aufgrund von REASON unter LOCATION die Aktion ACTION durchführen.

Beispiele:

Klicke auf Zahlungsinformationen.
Klicke unter dem Namen deiner Organisation auf Einstellungen.
Um deine Änderung zu bestätigen, klicke auf Kreditkarte entfernen.
Wenn du optional die Details deines Plans anzeigen möchtest, klicke auf Details anzeigen.
Klicken Sie unter „GitHub Sponsors“ rechts neben dem unterstützten Open-Source-Mitwirkenden auf direkt neben dem geleisteten Betrag, und klicken Sie dann auf Ebene ändern.

Produktnamen

Verwende vollständige Produktnamen. Kürze Produktnamen nicht ab. Eine Ausnahme gilt, wenn du Inhalte aus dem Produkt direkt wiedergibst (z. B. Benutzeroberflächenelemente oder API-Antworten). Produktnamen sind niemals besitzanzeigend.

Verwenden Sie Produktnamenvariablen, um Produktnamen zu rendern. Verwenden Sie keine Produktnamen im Nur-Text. Das vereinfacht die Implementierung von Produktnamensänderungen auf der gesamten Website und vermeidet Tippfehler in unseren Produktnamen. Weitere Informationen zu Produktnamenvariablen finden Sie unter „Wiederverwendbare Zeichenfolgen und Variablen“ in diesem Dokument und im Datenverzeichnis des Repositorys github/docs.

Produktnamen sind immer im Singular.

Verwenden: GitHub Actions unterstützt dich beim Automatisieren deiner Softwareentwicklungsworkflows.
Vermeiden: GitHub Actions unterstützen dich beim Automatisieren deiner Softwareentwicklungsworkflows.

Achten Sie darauf, zwischen Produktnamen und Produkt-Features zu unterscheiden. Produktfeatures sind immer Kleinbuchstaben.

Produkt	Funktion
GitHub Actions	eine Aktion
GitHub Codespaces	ein Codespace
GitHub Packages	ein Paket
GitHub Pages	eine GitHub Pages-Website

Schreiben Sie häufig verwendete Features wie Pull Requests, Themen oder Probleme nicht groß.

Produktspezifische Konventionen

In diesem Abschnitt werden zusätzliche Konventionen beschrieben, die für GitHub-Produkte spezifisch sind.

GitHub Actions

Wiederverwendbare Zeichenfolgen für Erstanbieteraktionen

Codebeispiele, die Erstanbieteraktionen verwenden, müssen die entsprechenden wiederverwendbaren Zeichenfolgen für diese Aktion verwenden. Dadurch können Aktualisierungen der Aktionsversion (z. B. von v1 in v2) für Produkte wie GitHub Enterprise Server einfacher verwaltet werden, die möglicherweise erst in einem zukünftigen GitHub Enterprise Server-Release dieselbe Aktionsversion zur Verfügung haben.

Wiederverwendbare Zeichenfolgen für Aktionen befinden sich in /data/reusables/actions/ und haben einen Dateinamen wie action-<action_name>.md

Verwende beispielsweise die wiederverwendbare Zeichenfolge, um die Aktion actions/checkout in einem Beispiel zu verwenden:

steps:
  - name: Checkout
    uses: actions/checkout@v4

Bei GitHub Docs ist eine Erstanbieteraktion jede Aktion, die das Präfix actions/, github/ oder octo-org/ aufweist. Dies ist beispielsweise eine Erstanbieteraktion:

steps:
  - uses: actions/checkout@v4

Haftungsausschluss für Drittanbieteraktionen

Codebeispiele, die Drittanbieteraktionen verwenden, müssen den folgenden Haftungsausschluss als Teil des Codeblocks enthalten:

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.

Verwende die wiederverwendbare Zeichenfolge {% data reusables.actions.actions-not-certified-by-github-comment %}{% endnote %}, um diesen Haftungsausschluss einzufügen.

Bei GitHub Docs ist eine Drittanbieteraktion jede Aktion, die nicht das Präfix actions/, github/ oder octo-org/ aufweist. Dies ist beispielsweise eine Erstanbieteraktion:

steps:
  - uses: actions/checkout@main

Dies ist ein Beispiel für eine Drittanbieteraktion:

steps:
    - uses: google-github-actions/setup-gcloud@1bee7de035d65ec5da40a31f8589e240eba8fde5

Beispiele:

Sieh dir den Codeblock unter Veröffentlichen in Paketregistrierungen an.

Anheften von Versionsnummern an SHA

Codebeispiele, die Aktionen von Drittanbietern verwenden, müssen immer an einen Commit-SHA mit voller Länge anstelle der Versionsnummer oder des Branchs angeheftet werden:

steps:
    - uses: google-github-actions/setup-gcloud@1bee7de035d65ec5da40a31f8589e240eba8fde5

Bei GitHub Docs ist eine Drittanbieteraktion jede Aktion, die nicht eines der folgenden Präfixe aufweist: actions/, github/ oder octo-org/. Dies ist beispielsweise eine Erstanbieteraktion:

steps:
  - uses: actions/javascript-action@main

Weitere Informationen findest du unter Verwenden von SHAs.

Codespaces

Wenn du dich auf das Produkt Codespaces beziehst, füge immer „GitHub“ ein, außer unter diesen Umständen:

shortTitle im Vordergrund.
In Zwischenüberschriften innerhalb eines Artikels, wenn „Codespaces“ bereits an einer beliebigen Stelle im Artikel vor der Zwischenüberschrift verwendet wurde

Variablen: {% data variables.product.prodname_github_codespaces %} (GitHub Codespaces) und {% data variables.product.prodname_codespaces %} (Codespaces)

Bezeichne Instanzen von Remotearbeitsumgebungen, die mit dieser Technologie erstellt wurden, als „Codespaces“. Verwende beispielsweise „um deinen Codespace zu löschen“ oder „um deine Codespaces aufzulisten“.

Verwenden immer „Entwicklungscontainer“ (in einem Wort), außer in Datei-/Pfadnamen. Die Ein-Wort-Form könnte als Marke angesehen werden, was wir vermeiden wollen, und wir wollen auch mit der Zwei-Wort-Form konsistent bleiben, die in der Dokumentation Visual Studio Code verwendet wird.

Verwende „Konfigurationsdateien für Entwicklungscontainer“, um auf alle Dateien im .devcontainer-Verzeichnis zu verweisen (plus .devcontainer.json, wenn diese anstelle von devcontainer.json im .devcontainer-Verzeichnis verwendet wird). Bezeichne diese nicht als „Entwicklungscontainerdateien“ oder „devcontainer-Dateien“, um zu vermeiden, dass dies als Verweis auf devcontainer.json-Dateien verstanden wird. „Konfigurationsdateien für Entwicklungscontainer“ bezieht sich auf alle Dateien, die zum Konfigurieren eines Entwicklungscontainers verwendet werden können, einschließlich Dockerfile- und docker-compose.yml-Dateien. Verwende nicht „die Konfigurationsdatei des Entwicklungscontainers“ (Singular), wenn du speziell auf eine devcontainer.json-Datei verweist. Verwende stattdessen den Namen der Datei.

GitHub Advanced Security (GHAS)

Verwende die Begriffe licenses und active committers, wenn du auf die GitHub Advanced Security-Abrechnung verweist.

Wir haben den Begriff seats verwendet, um die Anzahl der Konten zu beschreiben, die GitHub Advanced Security in einem Unternehmen verwenden können. Für Leser*innen kann der Begriff seats verwirrend sein, daher haben wir ihn im Herbst 2022 von GitHub.com entfernt, und in Versionen ab GHES 3.7 wird er nicht mehr verwendet.

Personal access tokens

GitHub verfügt über zwei Arten von personal access tokens:

Fine-grained personal access token: Präzise Steuerung des Repositoryzugriffs und der Berechtigungen
Personal access token: Verwende Bereiche, und gewähre Zugriff auf alle Repositorys, auf die der oder die Tokenbesitzer*in zugreifen kann.

Du solltest Variablen verwenden, um auf diese Tokentypen sowie auf personal access tokens im Allgemeinen zu verweisen:

Verwende {% data variables.product.pat_generic %}oder {% data variables.product.pat_generic_caps %}, um allgemein auf personal access token zu verweisen. Verwende {% data variables.product.pat_generic_title_case %}, wenn der Ausdruck mit Großbuchstaben („Personal Access Token“) beginnen soll, um dem Text auf der Benutzeroberfläche zu entsprechen.
Verwende {% data variables.product.pat_v2 %} oder {% data variables.product.pat_v2_caps %}, um auf fine-grained personal access token zu verweisen.
Verwende {% data variables.product.pat_v1 %}, {% data variables.product.pat_v1_plural %}, {% data variables.product.pat_v1_caps %} oder {% data variables.product.pat_v1_caps_plural %}, um auf personal access token zu verweisen.

Weitere Informationen zu den personal access tokens auf GitHub findest du unter Verwalten deiner persönlichen Zugriffstoken.

Interpunktion

Befolgen Sie außerdem die üblichen deutschen Interpunktionsregeln. Weitere Informationen findest du unter Interpunktion im Microsoft-Styleguide.

Versionshinweise

Versionshinweise zu GitHub Docs informieren Leserinnen über Änderungen für Administratorinnen oder Benutzer*innen an einer Version eines Produkts wie GitHub Enterprise Server (GHES). Versionshinweise erscheinen unter Versionshinweise.

Gute Versionshinweise bestehen aus einigen Sätzen, die die Fragen der Leser*innen zu der Änderung nacheinander beantworten. Weitere Informationen findest du unter Inhaltstyp der Versionshinweise.

Jeder Versionshinweis beschreibt eine der folgenden Änderungen.

Features: brandneues Verhalten oder neue Features
Sicherheitskorrekturen: Fixes für Risiken oder unerwartetes Verhalten mit Auswirkungen auf die Sicherheit
Fehlerbehebungen: Fixes für Fehler oder unerwartetes Verhalten
Änderungen: wichtige Änderungen am bisherigen Verhalten
Bekannte Probleme: Probleme, die von GitHub erkannt, aber noch nicht priorisiert wurden oder werden konnten
Veraltet: Entfernung eines Features oder Verhaltens
Errata: Korrektur an ungenauen Versionshinweisen oder Dokumentationen

Die Richtlinien zum Aktualisieren von Versionshinweisen findest du auch unter Hinzufügen oder Aktualisieren von Versionshinweisen.

Features

Versionshinweise für ein Feature fassen das brandneue Verhalten zusammen. Im Allgemeinen sind Versionshinweise für Features nur in Featurereleases enthalten.

Schreiben von Versionshinweisen für Features

Versionshinweise für ein Feature beantworten die folgenden Fragen:

Gilt dieses neue Feature für mich (mit meiner Rolle oder meinen Zugriffsberechtigungen)?
Welchem Zweck dient das Feature?
Was tut das Feature?
Wo kann ich ggf. mehr über das Feature erfahren?

ZIELGRUPPE (1) kann BESCHREIBUNG DES ZWECKS (2) durch BESCHREIBUNG DER VERWENDUNG DES FEATURES (3) erzielen. Weitere Informationen findest du unter ARTIKELTITEL (4).

Kategorisiere jedes Feature in einem Abschnitt unter einer Featureüberschrift.
Schreibe im Präsens.
Um Wiederholungen und unnötige Wörter zu reduzieren, wird das Hier und Jetzt in der Regel impliziert.
Vermeide den Passiv nach Möglichkeit, um die Akteure und Auswirkungen deutlich zu machen.

Beispiele für Versionshinweise zu Features

Websiteadministrator*innen können die Sicherheit der Verwaltungskonsole erhöhen, indem sie die Ratenbegrenzung für Anmeldeversuche sowie die Sperrdauer nach Überschreitung der Ratenbegrenzung konfigurieren. Weitere Informationen findest du unter Konfigurieren von Ratenbegrenzungen.
Unternehmensbesitzerinnen können steuern, wo Benutzerinnen Repositorys forken können. Das Forken kann auf voreingestellte Kombinationen aus Organisationen, die Organisation des übergeordneten Repositorys, Benutzerkonten oder auf alles beschränkt sein. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in deinem Unternehmen.
Benutzer*innen können Dateien mit geoJSON-, topoJSON- und STL-Diagrammen erstellen und die Diagramme auf der Weboberfläche rendern. Weitere Informationen findest du unter Arbeiten mit Nicht-Codedateien.

Sicherheitskorrekturen

Versionshinweise für einen Sicherheitsfix fassen eine Änderung zusammen, die der Ausnutzung eines sicherheitsbezogenen Problems im Produkt entgegenwirkt oder diese verhindert. Im Allgemeinen sind Versionshinweise für Sicherheitsfixes nur in Patchreleases enthalten.

Schreiben von Versionshinweisen für Sicherheitsfixes

Versionshinweise für einen Sicherheitsfix beantworten die folgenden Fragen:

Wie lautet der NVD-Schweregrad für das behobene Sicherheitsrisiko, falls vorhanden?
Welcher Angriff wäre durch das Ausnutzen des Sicherheitsrisikos möglich?
Welche Art von Sicherheitsrisiko kann ausgenutzt werden?
Wie lautet der CVE-Status (ausstehend oder aktiv) des Sicherheitsrisikos, falls verfügbar?
Hat jemand das Sicherheitsrisiko über das GitHub Bug Bounty-Programm gemeldet?

SCHWEREGRAD (1): Eine Angreiferin könnte BESCHREIBUNG DER AUSWIRKUNG (2) durch BESCHREIBUNG DES EXPLOITS (3) erzielen. GitHub hat die CVE-ID CVE-####-##### (4) für dieses Sicherheitsrisiko beantragt, das über das GitHub Bug Bounty-Programm (5) gemeldet wurde.

Beispiele für Versionshinweise für Sicherheitsfixes

MITTEL: Eine Angreiferin kann eine unbegrenzte Ressourcenauslastung in der Instanz verursachen, indem er oder sie parallele Anforderungen an die Markdown-REST-API stellt. Um dieses Problem zu beheben, hat GitHub CommonMarker aktualisiert. GitHub hat für dieses Sicherheitsrisiko die CVE-ID CVE-2022-39209 beantragt.
MITTEL: Eine Angreiferin könnte gefährliche Links in die Webbenutzeroberfläche der Instanz einbetten, da die Vorschaulinks für Pull Requests die URLs nicht ordnungsgemäß bereinigt haben. Dieses Sicherheitsrisiko wurde über das GitHub Bug Bounty-Programm gemeldet.

Basisimage- und Paketupdates

Wir enthalten auch Basisimage- und abhängige Paketupdates im Abschnitt „Sicherheitsupdates“, da diese Updates häufig Sicherheitsprobleme beheben. Wir konsolidieren alle diese Updates in der folgenden Notiz.

Die Pakete wurden auf die neuesten Sicherheitsversionen aktualisiert.

Fehlerkorrekturen

Versionshinweise für eine Fehlerbehebung beschreiben eine Korrektur eines unerwünschten oder anderweitig unerwarteten Verhaltens. Im Allgemeinen sind Versionshinweise für Fehlerbehebungen nur in Patchreleases enthalten.

Schreiben von Versionshinweisen für Fehlerbehebungen

Versionshinweise für eine Fehlerbehebung beantworten die folgenden Fragen:

War ich (mit meiner Rolle oder meinen Zugriffsberechtigungen) von diesem Verhalten betroffen?
Welches Verhalten würden die Benutzer*innen vor der Korrektur erleben?

ZIELGRUPPE (1) BESCHREIBUNG DES VERHALTENS (2).

Schreibe im Präteritum, da der Fehler behoben wurde.
Formulierungen wie „Ein Fehler wurde behoben ...“ oder „Ein Problem wurde behoben ...“ werden impliziert und sind unnötig.
Um Wiederholungen und unnötige Wörter zu reduzieren, wird das Hier und Jetzt in der Regel impliziert.
Vermeide den Passiv nach Möglichkeit, um die Akteure und Auswirkungen deutlich zu machen.
Wenn die Versionshinweise eine Fehlermeldung enthalten, formatieren Sie die Nachricht gemäß der Anleitung unter „Fehlermeldungen.“

Beispiele für Versionshinweise für Fehlerbehebungen

Nachdem ein Benutzer bzw. eine Benutzerin ein Repository mit aktiviertem Pushschutz importiert hat, war das Repository nicht sofort in der Ansicht „Sicherheitsabdeckung“ der Sicherheitsübersicht sichtbar.
Bei einer Instanz, auf der GitHub Actions aktiviert ist, wurden Workflowaufträge für GitHub Actions nicht gestartet, wenn die entsprechende Runnergruppe nicht verfügbar war, als der Auftrag ursprünglich in die Warteschlange gestellt wurde, selbst wenn die entsprechende Runnergruppe verfügbar wurde, nachdem der Auftrag in die Warteschlange eingereiht wurde.
Befehle, die Websiteadministrator*innen über SSH auf einem der Instanzknoten ausgeführt haben, wurden nicht in /var/log/ssh-console-audit.log angemeldet.

Änderungen

In Versionshinweisen für eine Änderung wird eine wichtige, aber geringfügige Änderung des vorhandenen Verhaltens beschrieben. Versionshinweise für Änderungen beantworten die folgenden Fragen.

Schreiben von Versionshinweisen für Änderungen

Versionshinweise für Änderungen beantworten die folgenden Fragen:

War ich (mit meiner Rolle oder meinen Zugriffsberechtigungen) von diesem Verhalten betroffen?
Welches Problem wird durch die Änderung behoben oder vermieden?
Was ist das neue Verhalten?
Falls relevant, wie war das Verhalten vor der Änderung?

ZIELGRUPPE (1) BESCHREIBUNG DES DURCH DIE ÄNDERUNG BEHOBENEN PROBLEMS (2) BESCHREIBUNG DES NEUEN VERHALTENS (3) BESCHREIBUNG DES ALTEN VERHALTENS (4).

Da die Änderung für das betreffende Release gilt, solltest du Versionshinweise für Änderungen im Präsens verfassen.
Um Wiederholungen und unnötige Wörter zu reduzieren, wird das Hier und Jetzt in der Regel impliziert.
Vermeide den Passiv nach Möglichkeit, um die Akteure und Auswirkungen deutlich zu machen.
Häufig wird die Zielgruppe impliziert.
Füge ggf. relevante Links zur GitHub-Dokumentation ein.

Beispiele für Versionshinweise für Änderungen

Bei einer Instanz mit einer GitHub Advanced Security -Lizenz können Benutzer*innen, die benutzerdefinierte Muster für die Geheimnisüberprüfung erstellen, Ausdrücke mit bis zu 2.000 Zeichen angeben, die übereinstimmen müssen oder nicht übereinstimmen dürfen. Diese Grenze ist eine Erhöhung von 1.000 Zeichen.
Für Administrator*innen, die SAML-Zuordnungen überprüfen oder ändern müssen, ist ghe-saml-mapping-csv -d der Standardpfad für die Ausgabe von /data/user/tmp anstelle von /tmp. Weitere Informationen findest du unter Befehlszeilenprogramme.
Um zeitweilige Probleme mit dem Erfolg von Git-Vorgängen in einer Instanz mit mehreren Knoten zu vermeiden, überprüft GitHub Enterprise Server den Status des MySQL-Containers, bevor versucht wird, eine SQL-Abfrage auszuführen. Die Timeoutdauer wurde ebenfalls reduziert.

Bekannte Probleme

In Versionshinweisen für ein bekanntes Problem wird ein Problem beschrieben, das von GitHub erkannt, aber noch nicht priorisiert wurde oder werden konnte.

Schreiben von Versionshinweisen für bekannte Probleme

Versionshinweise für bekannte Probleme beantworten die folgenden Fragen:

Bin ich (mit meiner Rolle oder meinen Zugriffsberechtigungen) von diesem Verhalten betroffen?
Welche Fehlermeldungen oder sonstigen erkennbaren Benutzeroberflächenelemente werden angezeigt?
Muss ich Maßnahmen ergreifen? Wenn ja, welche?

ZIELGRUPPE (1) BESCHREIBUNG DES PROBLEMS (2) DETAILS ZUM VERHALTEN (3) NÄCHSTE SCHRITTE (4).

Vermeide den Passiv nach Möglichkeit, um die Akteure und Auswirkungen deutlich zu machen.
Um Wiederholungen und unnötige Wörter zu reduzieren, wird das Hier und Jetzt in der Regel impliziert.
Wenn die Versionshinweise eine Fehlermeldung enthalten, formatieren Sie die Nachricht gemäß der Anleitung unter „Fehlermeldungen.“
Füge ggf. relevante Links zur GitHub-Dokumentation ein.
Bekannte Probleme sind auch eine Art von Inhalt auf GitHub-Dokumenten. Weitere Informationen finden Sie unter „Inhaltstyp zur Problembehandlung“. Falls nützlich, schreiben oder verknüpfen Sie sie mit ausführlicheren und kontextbezogenen Inhalten in den Dokumenten.

Beispiele für Versionshinweise für bekannte Probleme

Nachdem eine Benutzerin die Option für ein Repository aktiviert hat, um Benutzer*innen mit Lesezugriff das Erstellen von Diskussionen zu ermöglichen, ist das Feature nicht aktiviert.
Nachdem eine Administratorin eine Konfigurationsausführung gestartet hat, kann während der Überprüfungsphase für die Dienste „Notebook“ und „Viewscreen“ der Fehler No such object error auftreten. Dieser Fehler kann ignoriert werden, da die Dienste dennoch ordnungsgemäß gestartet werden sollten.

Veraltete Funktionen

Versionshinweise zu veralteten Features fassen ein Verhalten oder Feature zusammen, das GitHub entfernt hat oder das entfernt werden soll. Im Allgemeinen sind Versionshinweise für veraltete Features nur in Featurereleases enthalten.

Schreiben von Versionshinweisen für veraltete Features

Versionshinweise für veraltete Features beantworten die folgenden Fragen:

Gilt das bisherige Feature für mich (mit meiner Rolle oder meinen Zugriffsberechtigungen)?
Welches Feature wird eingestellt?
Wodurch wird das eingestellte Feature ggf. ersetzt?
Wo finde ich ggf. weitere Informationen?

ZIELGRUPPE (1) BESCHREIBUNG DES VERALTETEN FEATURES (2) ERSATZFEATURE (3) Weitere Informationen findest du unter ARTIKELTITEL (4).

Diese Versionshinweise werden im Präsens oder für bevorstehende Änderungen im Futur verfasst. Gib ggf. das bevorstehende Release an, in dem die Einstellung stattfindet.
Um Wiederholungen und unnötige Wörter zu reduzieren, wird das Hier und Jetzt in der Regel impliziert.
Vermeide den Passiv nach Möglichkeit, um die Akteure und Auswirkungen deutlich zu machen.
Kategorisiere jedes Feature in einem Abschnitt unter einer Featureüberschrift.

Beispiele für Versionshinweise für veraltete Features

Bevorstehende Einstellung: In GitHub Enterprise Server 3.8 und höher werden unsichere Algorithmen für SSH-Verbindungen mit der Verwaltungsshell deaktiviert, um Instanzen zu schützen.
Commitkommentare, d. h. Kommentare, die Benutzerinnen einem Commit außerhalb eines Pull Requests direkt hinzufügen, werden in der Pull Request-Zeitachse nicht mehr angezeigt. Benutzerinnen konnten diese Kommentare weder beantworten noch auflösen. Die REST-API für Zeitachsenereignisse und das PullRequest-Objekt der GraphQL-API geben ebenfalls keine Commitkommentare mehr zurück.

Fehler

Errata korrigieren falsche Informationen, die zuvor in den Versionshinweisen oder der Dokumentation für eine Version veröffentlicht wurden.

Schreiben von Errata

Errata beantworten die folgenden Fragen:

Welcher Abschnitt der Versionshinweise oder Inhalte zu GitHub Docs war ggf. betroffen?
Haben die falschen Informationen mich (mit meiner Rolle oder meinen Zugriffsberechtigungen) betroffen?
Was wurde in den Versionshinweisen oder der Dokumentation falsch beschrieben?
Wann wurden die Errata veröffentlicht?

INHALT (1) hat fälschlicherweise ausgesagt, dass ZIELGRUPPE (2) ZUSAMMENFASSUNG FALSCHER INFORMATIONEN (3) kann. [Aktualisiert: VERÖFFENTLICHUNGSDATUM4]

Formatiere das Veröffentlichungsdatum gemäß den Anweisungen unter Hinzufügen oder Aktualisieren von Versionshinweisen.

Beispiel für Errata

Features gibt fälschlicherweise an, dass Benutzer*innen von GitHub Advisory Database Empfehlungen für Elixir, den Hex-Paket-Manager von Erlang und vieles mehr sehen können. Dieses Feature ist in GitHub Enterprise Server 3.7 nicht verfügbar und wird in einem zukünftigen Release verfügbar sein. [Aktualisiert: 01.06.2023]

Hinzufügen oder Aktualisieren von Versionshinweisen

Um Leser*innen zu signalisieren, dass du eine Notiz hinzugefügt oder geändert hast, oder um das Veröffentlichungsdatum der Errata anzugeben, füge einen Datumsstempel im Format [Aktualisiert: TT-MM-JJJJ] an.

Wiederverwendbare Zeichenfolgen und Variablen

Verwende wiederverwendbare Zeichenfolgen für einzelne Substantive (z. B. Produktnamen) oder für vollständige Sätze oder Absätze. Satzfragmente und Ausdrücke sollten nicht in wiederverwendbaren Zeichenfolgen enthalten sein, da das bei der Lokalisierung zu Problemen führen kann. Weitere Informationen finden Sie im Datenverzeichnis im Repository github/docs unter „Erstellen wiederverwendbarer Inhalte“ und im Abschnitt „Produktnamen“ dieses Dokuments.

Abschnittsverzeichnis

Wenn ein Abschnitt eines Artikels H3- oder H4-Überschriften verwendet, um den Inhalt weiter aufzuteilen und nur ein Teil des Inhalts für einen Leserin relevant ist, kannst du ein Abschnittsverzeichnis verwenden, um Leserinnen zu helfen, die für sie relevanten Informationen zu erkennen und zu diesen zu navigieren. Beispielsweise richten die Leserinnen von Streamen des Überwachungsprotokolls für ein Unternehmen wahrscheinlich nur das Überwachungsprotokollstreaming für einen Anbieter ein, sodass das Abschnittsverzeichnis in „Einrichten des Überwachungsprotokollstreamings“ es ihnen ermöglicht, ihren Anbieter auszuwählen und zu den relevanten Inhalten zu navigieren, ohne den gesamten Abschnitt zu lesen.

Füge keinen Abschnittsverzeichnis hinzu, wenn H3- oder H4-Überschriften nur zum Gruppieren von Inhalten verwendet werden und alle Informationen für Leserinnen von Bedeutung sein könnten. Beispielsweise sollten die Leserinnen von Informationen zur Identitäts- und Zugriffsverwaltung jeden Abschnitt lesen und beachten, da diese für ihr Unternehmen gelten. In diesem Artikel wird kein Abschnittsverzeichnis verwendet, da die Leser*innen jeden Abschnitt durchlesen und nicht zwischen diesen auswählen sollen. Das Hinzufügen eines Abschnittsverzeichnisses würde auch Personen, die die Sprachausgabe oder andere adaptive Technologie verwenden, dazu zwingen, zwischen Registerkarten zu wechseln und durch mehr Überschriften zu scrollen, bevor sie zu den benötigten Informationen gelangen.

Formatiere Abschnittsverzeichnisse als Liste. Füge alle Unterabschnitte in der Reihenfolge ein, in der sie im Artikel vorkommen, und verweise mit der vollständigen Überschrift darauf.

Abschnittsverzeichnisse müssen mit einem Satz oder Absatz eingeführt werden, damit die Leser*innen nachvollziehen können, wie der Inhalt organisiert ist, und den Abschnitt auswählen können, der für sie am relevantesten ist. Füge kein Abschnittsverzeichnis direkt unter einer Überschrift ein.

Beispiel für Abschnittsverzeichnisse

## Setting up the application

Set up your application according to your operating system.

- [Setting up for macOS](#setting-up-for-macOS)
- [Setting up for Windows](#setting-up-for-windows)
- [Setting up for Linux](#setting-up-for-linux)

### Setting up for macOS

TEXT

### Setting up for Windows

The application is supported for all versions of Windows, but the set up steps differ.

- [Windows 98](#windows-98)
- [Windows Vista](#windows-vista)
- [Windows 11](#windows-11)

#### Windows 98

TEXT

#### Windows Vista

TEXT

#### Windows 11

TEXT

### Setting up for Linux

TEXT

Tabellen

Tabellen werden mithilfe von Markdown zu den GitHub Docs hinzugefügt. Da Tabellen schwierig zu lesen und zu pflegen sein können, sollten Sie sich vor der Erstellung einer Tabelle vergewissern, dass die Daten in einer Tabelle und nicht in einem anderen Format, z. B. einer Liste, am besten dargestellt werden. Jede Zeile in einer Tabelle muss mit einer Pipe, |, beginnen und enden.

Verwende Tabellen nur für die Darstellung tabellarischer Informationen

Tabellen funktionieren am besten für die Darstellung tabellarischer Daten, z. B. Informationen, die verglichen werden müssen, oder Werte mit mehreren Attributen. Verwende keine Tabellen für einfache Listen. Weitere Informationen findest du im Abschnitt Listen dieses Dokuments.

Beschreibe Tabellendaten nicht zu ausführlich

Die Daten einer Tabelle und deren Bedeutung sollten aus allen vorherigen Inhalten, den Spaltenüberschriften und (falls erforderlich) den Zeilenüberschriften klar hervorgehen. Vermeide nicht benötigte Beschreibungen der Daten in einer Tabelle. Wenn die Daten in einer Tabelle ohne eine langwierige Beschreibung unklar sind, solltest du überlegen, ob deine Tabelle Zeilenüberschriften benötigt oder die Informationen auf andere Weise kommuniziert werden sollten.

Beispielsweise wird unter Automatische Skalierung mit selbstgehosteten Runnern eine Tabelle, in der die Features von zwei unterstützten Lösungen für die automatische Skalierung verglichen werden, mit dem Satz Each solution has certain specifics that may be important to consider. eingeführt. Der Artikel beschreibt keines der unterschiedlichen Features, die verglichen werden, da diese Informationen von der Tabelle klar kommuniziert werden.

Verwenden: „Je nach GHES-Version gelten unterschiedliche Größengrenzwerte pro Repository.“
Vermeiden: „Die erste Zeile der Tabelle enthält die Informationen für GitHub Enterprise Cloud. In der zweiten Zeile sind die Informationen für GitHub Enterprise Server enthalten.“
Vermeiden: „Die folgende Tabelle zeigt, welche Migrationsdaten exportiert werden.“

Verwenden das richtige Markup für Zeilen- und Spaltenüberschriften

Tabellen, in denen die erste Spalte die Datenwerte in der Tabelle beschreibt, aber selbst keine Daten enthält, müssen mit Zeilenüberschriften gekennzeichnet werden. Dies ist wichtig für Hilfstechnologien, um die Beziehungen zwischen Zellen zu verstehen.

Um beispielsweise in der folgenden Tabelle die Werte „Ja“ und „Nein“ zu verstehen, muss sowohl die Spaltenüberschrift (Rolle) als auch die Zeilenüberschrift (Berechtigung) bekannt sein.

Organisationsberechtigung	Besitzer	Member	Moderatoren	Abrechnungsmanager	Sicherheitsmanager
Erstellen von Repositorys	Ja	Ja	Ja	Keine	Ja
Abrechnungsinformationen anzeigen und bearbeiten	Ja	Nr.	Nein	Ja	Nein
Personen zum Beitritt zur Organisation einladen	Ja	Nr.	Nr.	Nr.	Nein

Um Zeilenüberschriften für eine Markdowntabelle hinzuzufügen, umschließe die Tabelle mit den Liquid-Tags {% rowheaders %} {% endrowheaders %}. Weitere Informationen zur Verwendung des -Platzhalters finden Sie unter „Verwenden von Markdown und Liquid in GitHub Docs“.

Gib für jede Zelle einen Wert ein

Jede Zelle in einer Tabelle muss einen Wert enthalten.

Verwenden Sie für Zellen ohne Daten „Keine“ oder „Nicht zutreffend“. Verwende nicht „N/V“ oder „–“.

Bei Tabellen mit Zeilenüberschriften sollte die erste Zelle (Zelle „A1“) die Zeilenüberschriften beschreiben, damit die gesamte Tabelle verstanden werden kann. Wenn dies jedoch dazu führen würde, dass die Tabelle weniger klar ist oder redundante Informationen hinzugefügt wird, können Sie diese Zelle leer lassen. Beispielsweise könnte die erste Zelle im Artikel „Erstellen und Testen eines PowerShell-Projekts“ als „Module“ bezeichnet werden, da jede Zeilenüberschrift jedoch bereits das Wort „Modul“ enthält, würde diese Kopfzeile Informationen wiederholen, die keinen beschreibenden Wert zum Verständnis der Tabelle als Ganzes beitragen.

Verwende eindeutige, konsistente Symbole und Bezeichnungen

Für Tabellen, die Symbole verwenden:

Fülle alle Zellen. Markiere beispielsweise in einer Berechtigungstabelle nicht nur die Zellen für Aktionen, die eine Berechtigung erfordern.
Verwende Octicons oder SVG. Verwende keine Emojis. Weitere Informationen zu Opticons findest du unter „Verwenden von Markdown und Liquid in GitHub Docs“.
Verwende ein Häkchen für bestätigende Werte („Ja“, „Erforderlich“, „Unterstützt“) und ein Kreuz für negative Werte („Nein“, „Optional“, „Nicht unterstützt“).
Verwenden aria-label, um die Bedeutung des Symbols zu beschreiben, nicht seine visuellen Merkmale. Beispiel: „Erforderlich“, nicht „Häkchensymbol“.

Wenn Tabellendaten nicht binär sind (d. h. jeder Wert ist z. B. „Ja“ oder „Nein“), können zusätzlich zu oder anstelle von Symbolen Textwerte benötigt werden. Beispielsweise sind auf der Seite Informationen zum GitHub Support einige Features als „Zum Kauf verfügbar“ gekennzeichnet.

Verwende Fußnoten sparsam

Siehe Fußnoten.

Richte Tabelleninhalte einheitlich aus

Alle Spalten in einer Tabelle sollten linksbündig ausgerichtet sein. Eine Ausnahme sind Spalten, die nur Octicons enthalten. Diese sollten zentriert ausgerichtet sein. Wenn eine Spalte sowohl Text als auch Octicons enthält, verwende die zentrierte Ausrichtung.

Tabelleninhalt wird standardmäßig linksbündig ausgerichtet. Verwende die Markdowntabellenformatierung, also Doppelpunkte (:) rechts oder links von den Bindestrichen in der Kopfzeile, um die Ausrichtung der einzelnen Spalten anzugeben. Weitere Informationen findest du unter Informationen in Tabellen organisieren.

Das folgende Beispiel zeigt einen Teil einer Tabelle aus Konfigurationsoptionen für die Datei dependabot.yml.

Option	Erforderlich	Sicherheitsupdates	Versionsupdates	BESCHREIBUNG
`package-ecosystem`				Zu verwendender Paket-Manager
`directory`				Speicherort von Paketmanifesten
`schedule.interval`				Häufigkeit der Suche nach Updates

Die Tabelle wird mit der folgenden Ausrichtungssyntax generiert.

| Option              | Required | Security Updates | Version Updates | Description                    |
|---------------------|:--------:|:----------------:|:---------------:|--------------------------------|
| `package-ecosystem` |{% octicon "check" aria-label="Supported" %}|{% octicon "x" aria-label="Not supported" %}|{% octicon "check" aria-label="Supported" %}| Package manager to use         |
| `directory`         |{% octicon "check" aria-label="Supported" %}|{% octicon "x" aria-label="Not supported" %}|{% octicon "check" aria-label="Supported" %}| Location of package manifests  |
| `schedule.interval` |{% octicon "check" aria-label="Supported" %}|{% octicon "x" aria-label="Not supported" %}|{% octicon "check" aria-label="Supported" %}| How often to check for updates |

Titel

Verwende Anführungszeichen um Artikeltitel, unabhängig davon, ob der Artikel in der GitHub-Dokumentation oder an anderer Stelle erscheint. Schließe die Namen externer Websites nicht in Anführungszeichen ein.

Weitere Anleitungen findest du unter Formatieren von Titeln im Microsoft-Styleguide.

Kurztitel

Wir verwenden Kurztitel für die Seitenleiste. Da kurze Titel in der Randleistennavigation angezeigt werden, können sie den Kontext verwenden, um Bedeutung zu vermitteln und etwas präziser als vollständige Titel zu sein. Das Ziel von kurzen Titeln besteht darin, Personen bei der Suche nach Inhalten zu helfen, ohne dass navigationsleistenelemente zu lang sind. Kurze Titel geben Personen kontextbezogenes Verständnis eines Artikels und richten sich an die folgenden Standards.

Kurze Titel sind 2-3 Wörter lang.
- Bei Kategorien müssen kurze Titel weniger als 27 Zeichen lang sein.
- Bei Kartenthemen müssen kurze Titel weniger als 30 Zeichen lang sein.
- Bei Artikeln müssen kurze Titel weniger als 31 Zeichen sein und sind idealerweise zwischen 20 und 25 Zeichen.
Kurze Titel verwenden die Basisform von Verben anstelle von Gerunds.
- Verwenden Sie: "Benachrichtigungen konfigurieren" anstelle von "Konfigurieren von Benachrichtigungen".
Kurze Titel für Kategorien, Kartenthemen und Artikel können Produkt- und Featurenamen weglassen, wenn klar ist, auf welches Produkt oder Feature sie sich beziehen.
- Verwenden Sie: "Benachrichtigungen konfigurieren" als Kurztitel für "Konfigurieren von Benachrichtigungen für Dependabot-Warnungen", da sich der Artikel im Kartenthema "Dependabot alerts" befindet.
Kurztitel führen keine neuen Wörter ein, die nicht im vollständigen Titel enthalten sind.
Kurztitel für ähnliche Inhalte sollten einheitlich formuliert sein.
- Verwenden Sie: "Organisationen und Teams" und "Unternehmenskonten"
- Vermeiden Sie: "Organisationen und Teams" und "Verwalten von Unternehmenskonten"

Das Schreiben von Kurztiteln kann schwierig sein. Um Kurztitel unter der Zeichenanzahl zu erhalten, sollten Sie den Kurztitel im Kontext berücksichtigen. Entfernen Sie alle wiederholten Wörter, sofern möglich, und alle Produkt- oder Featurenamen, die sich im Kartenthema oder in der Kategorie befinden, zu denen der Inhalt gehört.

Websiterichtlinieninhalt

Verwenden Sie keine wiederverwendbaren Elemente oder Variablen in Websiterichtlinieninhalten. Websiterichtlinienartikel sind juristische Dokumente und müssen über eine von Menschen lesbare Quelle verfügen.

Websiterichtlinieninhalte verwenden andernfalls denselben Stil und dieselben Inhaltsmodelle wie die restlichen GitHub Docs.

Benutzeroberflächenelemente

Fettdruck

Verwende Fettdruck, um UI-Elemente hervorzuheben, mit denen interagiert werden kann.

Klicke auf der linken Randleiste auf Abrechnung.
Suche unten auf der Registerkarte Diskussion des Pull Request nach dem Mergefeld.
Füge neben Titel eine beschreibende Bezeichnung für deinen neuen Schlüssel hinzu.

Branchnamen

Verwende Codeformatierung für Branchnamen.

main
USERNAME.github.io

Schaltflächen

Formatiere Schaltflächennamen fett, und lasse das Wort „Schaltfläche“ nach Möglichkeit weg. Verwende „klicken“ statt „drücken“, um die Verwendung einer Schaltfläche zu beschreiben.

Verwenden: Klicke auf Pull Request.
Vermeiden: Drücke die Pull Request-Schaltfläche.

Kontrollkästchen

Formatiere die Namen von Kontrollkästchen fett, und lasse das Wort „Kontrollkästchen“ weg. Verwende „aktivieren“ oder „deaktivieren“, um die Verwendung eines Kontrollkästchens zu beschreiben.

Verwenden: Aktiviere Für alle neuen Repositorys aktivieren.
Vermeiden: Wähle das Kontrollkästchen „Für alle neuen Repositorys aktivieren“ aus.

Dynamischer Text

Verwende Großbuchstaben, um Text anzugeben, der sich auf der Benutzeroberfläche ändert oder den Benutzer*innen in einem Befehl oder Codeausschnitt angeben müssen.

Verwenden: Klicke auf BENUTZERNAME zu REPOSITORYNAME hinzufügen.

Listen und Listenelemente

Formatiere Listen und anklickbare Listenelemente fett. Wenn du die Interaktion mit einer Liste beschreiben möchtest, z. B. ein Dropdownmenü oder ein Benutzeroberflächenelement, das aufgeklappt wird, verwende das Verb „auswählen“ – unabhängig davon, ob es sich bei dem Listennamen um ein Wort oder ein Octicon handelt. Um die Auswahl eines Listenelements zu beschreiben, verwende „klicken“.

Verwenden: Wähle das Dropdownmenü E-Mail-Adressen sichern aus, und klicke auf Nur primäre E-Mail-Adressen zulassen.
Vermeiden: Klicke auf das Dropdownmenü „E-Mail-Adressen sichern“, und klicke auf Nur primäre E-Mail-Adressen zulassen.

Standort

Beschreibe die Position eines Benutzeroberflächenelements mit den üblichen Begriffen.

unter oder über
Neben
oben links, oben rechts, unten links, unten rechts
oben auf der Seite, unten auf der Seite, rechts auf der Seite, links auf der Seite

Panels

Vermeide nach Möglichkeit, auf Panels zu verweisen. Beschreibe stattdessen, was jemand tun muss.

Verwenden: Klicke auf Diagramme anzeigen für dein Repository, und wähle dann im Dropdownmenü den Zeitraum aus, den du anzeigen möchtest.
Verwenden: Klicke auf Diagramme anzeigen, um das Panel für dein ausgewähltes Repository zu öffnen, und wähle dann im Dropdownmenü den Zeitraum aus, den du anzeigen möchtest.

Wenn du auf einen Bereich verweisen musst, um eine Änderung an der Benutzeroberfläche zu beschreiben oder die Interaktion mit der Benutzeroberfläche zu erläutern, formatiere den Bereichsnamen als Benutzeroberflächentext. Verwende das Wort „Panel“ nur, wenn es dem Verständnis dient oder der Bereich keinen Namen auf der Benutzeroberfläche hat.

Verwenden: Wähle im Bereich „Sicherheitsabdeckung“ die Option Aktivieren oder Deaktivieren aus.
Verwenden: Wähle im Panel Aktivieren oder Deaktivieren aus.

Optionsfelder

Formatiere die Beschriftung von Optionsfeldern fett, und lassen die Wörter „Optionsfeld“ oder andere Beschreibungen weg. Verwende „auswählen“, um die Verwendung eines Optionsfelds zu beschreiben.

Repositorynamen

Formatieren von Repositorynamen in Monospace-Schriftart mit Backticks. Stellen Sie einen Link zu Repositorys bereit, wenn erwartet wird, dass Personen zu ihnen navigieren.

Verwendung: Siehe das github/docs-Repository für weitere Informationen.

Responsive Elemente

Wir dokumentieren den responsiven Status von Benutzeroberfläche-Elementen nur dann, wenn sie zu Mehrdeutigkeit oder Verwirrung führen. Wenn eine Aufgabe aufgrund eines responsiven Benutzeroberfläche-Elements unklar ist, beschreiben Sie die Interaktion, die jemand durchführen muss, um das Ziel der Aufgabe zu erreichen. Beschreiben Sie nicht nur den visuellen Status des Benutzeroberfläche-Elements.

Verwenden Sie: Klicken Sie auf Sicherheit. Wenn die Sicherheit nicht sichtbar ist, klicken Sie auf ⋮, um das Repositorymenü zu erweitern.

Benutzeroberflächentext

Wenn du dich auf Text auf der Benutzeroberfläche beziehst, solltest du diesen genau wiedergeben. Schließe Benutzeroberflächentext in Anführungszeichen ein, mit dem nicht interagiert werden kann.

Verwenden: Klicke unter „IP-Zulassungsliste“ auf Bearbeiten.

Weitere Ressourcen

Microsoft-Styleguide:

Formatieren von Text in Anweisungen

Videos

Du kannst Videos hinzufügen, um textbasierte Informationen zu ergänzen, aber Videos sollten nie schriftliche Inhalte ersetzen. Videos sind für einige Benutzer nicht zugänglich und auch schwer zu suchen.

Videos in der GitHub-Dokumentation müssen gut produziert sein, möglichst wenige Barrieren für Menschen mit Behinderungen enthalten und unserem Inhaltsmodell für Videos entsprechen. Weitere Informationen findest du unter Informationen zur Verwendung von Videos in der GitHub-Dokumentation.

Sprache und Tonfall

Verwende eine klare, einfache Sprache, die für ein breites Publikum verständlich ist. Sei authentisch, einfühlsam und selbstsicher beim Schreiben.

Schreibe für deine Zielgruppe: Einige Jargon- und Fachbegriffe sind notwendig, aber gehe nicht davon aus, dass alle Leser*innen über das gleiche Maß an technischem Fachwissen verfügen.

Verwenden Sie die Aktivform, wenn möglich. Passivformen sind akzeptabel, wenn Sie das Objekt einer Aktion hervorheben müssen.

Wir sind eine globale Entwicklercommunity. Vermeide Ausdrücke, Redewendungen und Slangbegriffe, die für eine bestimmte Region oder ein bestimmtes Land typisch sind.

Weitere Informationen zum Schreiben von ansprechbaren Inhalten findest du unter Der Microsoft-Stil: einfach und menschlich und Die zehn Top-Tipps zum Microsoft-Stil.

Wortwahl und Terminologie

Allgemeine Anleitungen und GitHub-spezifische Begriffe findest du in unserem Glossar. Ausführlichere Informationen findest du in der Wortliste von A bis Z im Microsoft-Styleguide.

Abkürzungen

Schreibe Wörter aus, außer wenn es sich um ein Wort handelt, das im Produkt selbst explizit gekürzt wird.

Verwenden: Repository
Vermeiden: Repo
Verwenden: Administrator, Personen mit Administratorberechtigungen
Vermeiden: Admins

Verwende keine Symbole oder Octicons, die nicht auf der Benutzeroberfläche von GitHub verwendet werden.

Verwenden: Klicke auf Dateiund dann auf Bearbeiten.
Vermeiden: Klicke auf Datei > Bearbeiten.

Konten

Produktnamen und Konten

Um Mehrdeutigkeiten und Verwirrung zu vermeiden, verwende keine Produktnamen wie Adjektive, um Konten in unseren Produkten zu beschreiben. Erkläre stattdessen den Kontotyp, und wähle eindeutige Formulierungen, die eine Verwechslung der Konten und Produkte vermeiden. Verwende in Bezug auf Konten nur dann Produktnamen, wenn dies erforderlich ist, um zwischen den Produkten zu unterscheiden. Weitere Informationen zu verschiedenen Konten, die in GitHub-Produkten verfügbar sind, findest du unter Arten von GitHub-Konten.

Verwenden: Deine Organisation auf GitHub Enterprise Cloud
Vermeiden: Dein GitHub Enterprise Cloud-Konto
Vermeiden: Deine GitHub Enterprise Server-Organisation
Verwenden: Du kannst deine Arbeit auf GitHub Enterprise Server hervorheben, indem du die Anzahl deiner Beiträge in dein Profil auf GitHub.com überträgst.

Konten von Einzelpersonen auf GitHub

Für Konten von Einzelpersonen verwenden wir je nach Kontext unterschiedliche Bezeichnungen.

Wenn es sich bei dem Inhalt nicht um die Verwaltung eines Unternehmensprodukts handelt, solltest du das Konto einer Einzelperson auf GitHub als „persönliches Konto“ bezeichnen. Das sorgt für Konsistenz mit der Benutzeroberfläche und verhindert, dass Leser*innen verwirrt werden, weil zwei Begriffe verwendet werden, die dasselbe bedeuten.

Verwenden: Erstellen geplanter Erinnerungen für dein persönliches Konto
Vermeiden: Erstellen geplanter Erinnerungen für dein Benutzerkonto

Konten für Unternehmensprodukte

Mit den Unternehmensprodukten von GitHub verwalten Administrator*innen eine Unternehmenskonto. Ein Enterprise-Konto kann mehrere Organisationen besitzen, und die Benutzerkonten von Personen können Mitglieder der Organisationen sein. Weitere Informationen findest du im Artikel „Rollen in einem Unternehmen“ für jedes Produkt.

Wenn der oder die Leser*in ein Unternehmenskonto verwaltet und du dich auf die Konten der Personen beziehst, die sie verwalten, verwende „Benutzerkonto“. Das gilt für die folgenden Produkte:

GitHub Enterprise Cloud mit Enterprise Managed Users
- Verwenden: Mit Enterprise Managed Users können Sie Benutzerkonten für Unternehmensmitglieder erstellen und verwalten.
- Vermeiden: Mit Enterprise Managed Users können Sie persönliche Konten für Unternehmensmitglieder erstellen und verwalten.
GitHub Enterprise Server
- Verwenden: Wenn Sie vorübergehend ein Benutzerkonto übernehmen müssen ...
- Vermeiden: Wenn Sie vorübergehend ein persönliches Konto übernehmen müssen …

In der folgenden Dokumentation sollte „Benutzerkonto“ verwendet werden:

Das Produkt Dokumentation für Enterprise-Administratoren
Unternehmensspezifische Abrechnungsdokumentation, z. B. Informationen zur Abrechnung für dein Unternehmen
Inhalte in anderen Produkten, die für Administrator*innen bestimmt sind, z. B. Bewährte Methoden zum Schützen von Konten im Produkt „Codesicherheit“ oder Eine Testversion von GitHub Enterprise einrichten im Produkt „Erste Schritte“
Unternehmensspezifische API-Inhalte, z. B. die REST-API-Referenzdokumentation REST-API-Endpunkte für die GitHub Enterprise-Verwaltung

Für Unternehmen in GitHub Enterprise Cloud, die Enterprise Managed Users nicht verwenden, solltest du „persönliches Konto“ verwenden, wenn Mitglieder von Organisationen gemeint sind, die zum Unternehmen gehören.

Verwenden: Wenn du SAML-SSO konfigurierst, melden sich die Mitglieder deiner Organisation weiterhin bei ihren persönlichen Konten bei GitHub.com an.
Vermeiden: Wenn du SAML-SSO konfigurierst, melden sich die Mitglieder deiner Organisation weiterhin bei ihren Benutzerkonten bei GitHub.com an.

Die Dokumentation, die GitHub Enterprise Cloud ohne Enterprise Managed Users beschreibt, befindet sich in der Regel in der Kategorie SAML Single Sign-On für deine Organisation verwalten.

Konten für andere Dienste

Wenn du dich auf das Konto einer Person für einen anderen Dienst als GitHub beziehst, z. B. einen Integrations- oder Authentifizierungsanbieter, verwende „Benutzerkonto“.

Akronyme

Schreibe Akronyme aus, wenn sie zum ersten Mal in einem Artikel verwendet werden, außer in Titeln oder Überschriften.

Apps

Verwende „App“ oder „Anwendung“ in allgemeinen Inhalten.

Verwenden: Veröffentlichen und Listen deiner App im GitHub Marketplace

Verwende „App“, wenn du auf OAuth apps verweist, da es sich hierbei nicht um ein Produkt handelt.

Verwenden: Registrieren einer OAuth app
Vermeiden: Registrieren einer OAuth-Anwendung

Verwende „App“, wenn du auf GitHub Apps verweist, da es sich hierbei um ein Produkt handelt.

Verwenden: Registrieren einer GitHub App

GitHub Apps und OAuth apps bestehen aus zwei Komponenten: der App-Registrierung und dem Code, der die App dazu bringt, etwas zu tun.

Verwende Begriffe wie „registrieren“ und „GitHub App-Registrierung“, um nur auf die GitHub App- Einstellungen bzw. -Konfigurationen auf der Benutzeroberfläche von GitHub zu verweisen.
- Verwenden: Registrieren einer GitHub App
- Verwenden: Aktualisieren einer GitHub App-Registrierung
- Vermeiden: Erstellen einer GitHub App
- Vermeiden: Ändern einer GitHub App
Um nur auf den Code für die App zu verweisen, verwenden Formulierungen wie „Code für deine App“ oder „Code deiner App“.
- Verwenden: Code für deine App
- Verwenden: Code für deine GitHub App
- Verwenden: Code deiner App
- Vermeiden: Deine GitHub App
- Vermeiden: Deine OAuth app
Wenn du dich auf die App als Ganzes (Registrierung und Code) beziehst, solltest du sie als GitHub App oder OAuth app bezeichnen.

GitHub Apps kann in Organisations- und Benutzerkonten installiert werden. Um auf eine Installation der App zu verweisen, verwende „GitHub App-Installation“ anstelle von „GitHub App“.

Währung

Wenn du Währungsangaben oder das $-Zeichen verwendest, musst du sicherstellen, dass die Währung definiert ist, auch wenn der Betrag 0 ist. Verwende nach Möglichkeit den Währungsnamen gemäß ISO-Standard und den Währungscode gemäß ISO-Standard.

Der Hinweis auf das Land oder die Region sollte in Großbuchstaben geschrieben sein.

Verwenden: US-Dollar
Vermeiden: Us-Dollar, $USD-Dollar

Verwende Großbuchstaben für Währungscodes.

Verwenden: USD

Wenn es nur eine Erwähnung in einem Artikel gibt, verwende den Währungsnamen ohne das $-Zeichen vor dem Betrag.

Verwenden: 10 US dollars für eine einzige Erwähnung der Währung

Wenn ein Artikel mehrere Erwähnungen derselben Währung enthält, stelle sicher, dass bei der ersten der Währungsname ohne $-Zeichen vor dem Betrag verwendet wird und der Währungscode in Klammern nach dem Währungsnamen enthalten ist.

Füge für nachfolgende Erwähnungen von Währungen in einem Artikel oder bei Bedarf (z. B. bei Zeichenbeschränkungen oder wenn mehrere Beträge in einer Tabelle oder Liste vorhanden sind) das $-Zeichen vor dem Betrag ein, und verwende den ISO-Währungscode nach dem Betrag.

Verwenden: 10 US dollars (USD) für die erste Erwähnung und $0.25 USD für nachfolgende
Vermeiden: $10 US dollars (USD), USD$0.25

Wenn es sich bei der ersten Erwähnung um einen Cent-Betrag oder eine andere Währung als Dollar handelt, sollten Sie das Land oder die Region der Währung in Klammern unmittelbar nach der ersten Erwähnung in Großbuchstaben angeben. Nachfolgende Währungsangaben werden gemäß den oben genannten Richtlinien behandelt.

Verwenden: 99 cents (US currency) für die erste Erwähnung und 99 cents für nachfolgende
Vermeiden: $0.99 (US currency), $0.99 USD cents, USD$0.99 cents

Berechtigungen

Eine Berechtigung ermöglicht es, eine bestimmte Aktion auszuführen. Die Möglichkeit, ein Issue zu löschen, ist beispielsweise eine Berechtigung.

Eine Rolle vereint verschiedene Berechtigungen, die Benutzer*innen zugewiesen werden können. Es gibt Rollen auf verschiedenen Ebenen.

Konten (z. B. Organisationsbesitzer, Abrechnungsmanager für einen Unternehmenskonto)
Ressourcen (z. B. Schreiben für ein Repository, Administrator für eine Sicherheitsempfehlung)
Teams (z. B. Teamverwalter)

Der Zugriff einer Person bezieht sich im Allgemeinen auf alle Möglichkeiten, die die Person in einem bestimmten Kontext hat, unabhängig davon, aus welchen Rollen oder einzelnen Berechtigungen diese stammen.

Verwende nur die Berechtigung oder Rolle, wenn die Unterscheidung zwischen diesen beiden Begriffen wichtig ist. Verwende andernfalls Zugriff.

Verwenden: Um eine benutzerdefinierte Repositoryrolle zu erstellen, wählen Sie eine geerbte Rolle, und fügen Sie dann einzelne Berechtigungen hinzu.
Verwenden: Verwalten des Zugriffs auf die Repositorys Ihrer Organisation
Verwenden: Wenn Ihre Teammitgliedschaft Ihnen einen anderen Zugriffsumfang bietet als Ihre Rolle als Organisationsbesitzer ...
Verwenden: Personen mit Schreibzugriff können ...
Vermeiden: Personen mit der Schreibzugriff können ...
Vermeiden: Personen mit der Schreibrolle können ...
Vermeiden: Personen mit Schreibberechtigungen können ...
Vermeiden: Personen mit Schreibrechten können ...

Wenn du den Zugriff angibst, der zum Ausführen einer Aktion erforderlich ist, erwähne nur die Rolle auf derselben Ebene wie die Aktion. Beispielsweise benötigst du Administratorzugriff auf ein Repository, eine Rolle auf Repositoryebene, um geschützte Branches zu konfigurieren. Du kannst Administratorzugriff auf ein Repository erhalten, indem du Organisationsbesitzer bist, eine Rolle auf Organisationsebene, aber die Rolle auf Repositoryebene bestimmt letztendlich, ob die Aktion möglich ist. Deshalb ist das die einzige Rolle, die erwähnt werden sollte.

Verwenden: Personen mit Schreibzugriff auf ein Repository können X für das Repository ausführen.
Vermeiden: Organisationsbesitzer und Personen mit Schreibzugriff können X für das Repository ausführen.

Weitere Informationen zur Wortwahl für Angaben zu Berechtigungen findest du unter „Inhalt eines GitHub-Docs-Artikels“ im Inhaltsmodell.

Präpositionen

Vermeide es, einen Satz mit einer Präposition zu beenden, es sei denn, der Satz andernfalls merkwürdig oder zu formal klingen.

Produktnamen

Weitere Informationen findest du im Abschnitt Produktnamen dieses Leitfadens.

Zu verwendende oder vermeidende Begriffe

Zweck	Vermeiden
person	Benutzer, Kunde
terminal	Shell
username	login
Anmelden	einloggen
Registrieren	anmelden
empfohlener Grenzwert	weicher Grenzwert
email	E-Mail
frontmatter	Frontmatter
auf GitHub	in einem Remoterepository
drücken (eine Taste)	tippen
eingeben (auf der Benutzeroberfläche)	eintippen (auf der Benutzeroberfläche)
eingeben (in der Befehlszeile)	eintippen (in der Befehlszeile)

Wortwahl

Mehrdeutige Verben

Wenn ein Vorgang erforderlich ist oder eine Option einer anderen vorgezogen wird, vermeiden Sie die Verwendung von mehrdeutigen modalen Hilfsverben wie „kann“, „könnte“, „soll“, „sollte“, „könnte“, „könnte“, „würde“ und „kann“. Diese Verben können entweder als Befehl oder als Vorschlag interpretiert werden. Verwenden Sie stattdessen Verben, die eindeutig angeben, ob die Aktion erforderlich oder optional ist. Wenn etwas eine Option oder ein Vorschlag ist, können Sie diese Verben verwenden, solange Sie deutlich machen, dass die Aktion optional ist.

Verwenden: Sie können entscheiden, welche Tastenkombinationen verwendet werden sollen.
Verwenden: Verwenden den git clone-Befehl zum Klonen des Repositorys.
Vermeiden: Sie können den git clone-Befehl verwenden, um ein Repository zu klonen.
Vermeiden: Sie könnten das Branch löschen.

Unsichtbarer Plural

Vermeiden Sie den unsichtbaren Plural, bei denen es sich um Wörter handelt, die mehrdeutige Bedeutung haben, da sie als Singular oder Plural interpretiert werden können. Beispielsweise könnte „file retrieval“ auf das Abrufen einer einzelnen Datei oder mehrerer Dateien verweisen.

Verwenden: Nachdem die Datei abgerufen wurde, wählen Sie aus, wo sie gespeichert werden soll.
Vermeiden: Wählen Sie nach dem Abrufen der Datei den Speicherort aus.

Substantivierungen

Vermeiden Sie Substantivierungen, bei denen es sich um Substantive handelt, die aus Verben oder Adjektiven erstellt werden. Substantivierungen können Sätze länger machen, schwieriger zu verstehen und schwieriger zu übersetzen.

Verwendung: Nach Abschluss des Workflows wird das Paket angezeigt.
Vermeiden: Nachdem der Workflow sein Ende erreicht hat, wird das Paket angezeigt.

Aneinanderreihungen von Nomen

Vermeide die Verwendung aneinandergereihter Wörter (zusammengesetzte Substantive), da sie zu Fehlübersetzungen führen können, weil die Übersetzerinnen nicht bestimmen können, welche Wörter sich aufeinander beziehen. Formuliere die Aneinanderreihung mithilfe von Präpositionen um. Wenn eine Aneinanderreihungen von Nomen unerlässlich ist, solltest du auf eindeutige Hintergrundinformationen und ausreichend Kontext achten, damit die Leserinnen und Übersetzer*innen die Bezüge verstehen.

Verwenden: Standardquelleinstellungen für öffentliche Repositorys
Vermeiden: Öffentliche Repositorystandardquelleinstellungen

Unklare Nomen und Pronomen

Wenn ein Pronomen über mehr als ein Bezugswort verfügt, kannst du entweder den Satz umformulieren, um das Bezugswort klar zu machen, oder das Pronomen durch ein Nomen ersetzen, um Mehrdeutigkeit zu vermeiden.

Verwendung: Nachdem Sie sich endgültig für Ihren Branch entschieden haben und Ihre Pull Request zusammengeführt haben, können Sie Ihren Branch löschen.
Vermeiden: Nachdem Sie sich endgültig für Ihren Branch entschieden haben und Ihre Pull Request zusammengeführt haben, können Sie Ihren Branch löschen.

Not to be confused with Davy Jones of The Monkees ↩
Also humans ↩