Stil-Leitfaden

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 am besten ist. Wir sind flexibel und offen für Änderungen, wobei wir gleichzeitig auf Einheitlichkeit achten.
• Um den Styleguide anzupassen, wenn unser Team und die Dokumentationssätze wachsen, und um hochwertige, aussagekräftige Inhalte zu erstellen, die den Benutzer*innen dient, konzentrieren wir uns auf wesentliche 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 ein Reviewer nachfragt, sind wir darauf vorbereitet, die Entscheidung zu besprechen.

Prüfprotokollereignisse

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

•         [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/security-log-events)
  

•         [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)
  

•         [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise)
  

Wenn Sie die Beschreibung für ein Überwachungsprotokollereignis formulieren, beschreiben Sie das aufgetretene Event auf eine Weise, die auf alle Versionen zutrifft. Verwenden Sie dabei Präteritum und Passiv. Beginnen Sie 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:** Ein Organisationsbesitzer hat die Zwei-Faktor-Authentifizierung für die Organisation deaktiviert.
  

•         **Vermeiden:** Wird ausgelöst, wenn Benutzer aktualisieren, auf welche Repositorys ein Codespace zugreifen kann.
  

Warnhinweise

Warnhinweise heben Informationen innerhalb eines Artikels hervor, die von besonderer Bedeutung sind und eine Unterbrechung des Informationsflusses rechtfertigen.

Verwende Warnhinweise selten. Warnhinweise dürfen nicht aufeinander folgen oder mehr als einmal pro Abschnitt verwendet werden.

Warnhinweise müssen kurz und präzise sein. Wenn die Informationen aus mehr als ein paar Sätzen bestehen oder eine sortierte oder ungeordnete Liste erfordern, ist es vielleicht ratsam, die Informationen unter Abschnittsüberschriften zu platzieren.

Arten von Warnhinweisen

Wir verwenden fünf Arten von Warnungen: Hinweis, Tipp, Wichtig, Warnung und Vorsicht.

Hinweis

Bietet zusätzlichen Kontext, den Benutzer möglicherweise berücksichtigen müssen. Aufgaben können ohne die Informationen aus Warnhinweisen ausgeführt werden. In manchen Kontexten können bestimmte Benutzer jedoch von dem Hinweis profitieren.

Hinweise sind besonders nützlich für die Übermittlung von Informationen, die für den beschriebenen Prozess nicht von zentraler Bedeutung sind:

• Vorbehalte, die sich auf das Ergebnis eines Prozesses auswirken können, wie z. B. bestimmte Benutzereinstellungen.

• Produkte und Funktionen, deren Verfügbarkeit Änderungen unterliegt, z. B. in öffentliche Vorschau oder schließen.

          [AUTOTITLE](/code-security/secret-scanning/managing-alerts-from-secret-scanning/evaluating-alerts#reviewing-github-token-metadata) nutzt beispielsweise einen Hinweis, um die Benutzer darüber zu informieren, dass sich die Metadaten für GitHub-Token derzeit in der öffentliche Vorschau befinden.
  

Tipp

Empfehlungen, bewährte Methoden und Produkthinweise. Tipps enthalten unwesentliche Informationen, die die Benutzer im eigenen Ermessen befolgen können oder nicht. Besonders nützlich sind sie bei Artikeln, die sich an neue Benutzer richten.

Beispielsweise verwendet Personalisieren deines Profils einen Tipphinweis, um Benutzern zu helfen, zu verstehen, was sie erwarten können, wenn sie ein @mention für eine Organisation ausführen.

Wichtig

Es werden wichtige Informationen hervorgehoben, die Benutzende wissen müssen, um ihr Ziel zu erreichen.

Warnung

Macht auf potenzielle Risiken aufmerksam, die ein Benutzer vor dem Beginn oder Fortsetzen einer Aufgabe beachten sollte.

Warnungen sind besonders relevant für Prozesse, die außerhalb der Benutzeroberfläche von GitHub ablaufen, z. B. in der Befehlszeile oder über eine API.

          [AUTOTITLE](/enterprise-cloud@latest/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities) enthält z. B. Anweisungen für die Befehlszeile und verwendet eine Warnung, um Benutzer darauf hinzuweisen, dass einmal ausgestellte Zertifikate nicht mehr widerrufen werden können:

Vorsicht

Warnt Benutzer vor gefährlichen oder destruktiven Aktionen, die extreme Vorsicht erfordern, bevor sie ausgeführt werden – vor allem, wenn ein Sicherheitsrisiko oder ein Datenverlustrisiko besteht.

Vorsichtshinweise sind in der Regel nur erforderlich, wenn Prozesse beschrieben werden, die außerhalb der Benutzeroberfläche von GitHub auftreten, z. B. in der Befehlszeile oder über eine API.

Formatierung von Warnhinweisen

Wir haben die Formatierung und Farben für verschiedene Arten von Warnhinweisen in der gesamten Dokumentation standardisiert.

Warnhinweise werden mit Markdown gerendert.

Hinweis:

> [!NOTE]
> Keep this in mind.

Tipp:

> [!TIP]
> Here's a suggestion.

Warnung:

> [!WARNING]
> Be careful.

Vorsicht:

> [!CAUTION]
> Be extremely careful.

Liquid-Syntax für Warnhinweise wird weiterhin unterstützt und kann weiterhin in älteren Artikeln erscheinen, sollte jedoch nicht für neue Warnhinweise verwendet werden.

Weitere Informationen zum Formatieren von Warnhinweisen findest du unter „Warnhinweise“ in Verwenden von Markdown und Liquid in GitHub Docs.

Handlungsaufforderung (Call to Action, CTA)

Ein CTA ist ein Link oder eine Schaltfläche, über die Benutzer aufgefordert werden, den nächsten Schritt zu machen. Ein Benutzer wird an einen anderen Ort weitergeleitet.

Die Schlüsselkomponente eines CTA besteht darin, dass die benutzende Person dabei unterstützt wird, die gewünschte Aktion auszuführen. Hierzu wird sie zum nächsten Schritt oder zu einem erforderlichen Produkt oder Feature weitergeleitet.

Wenn Sie überlegen, wann Sie einen CTA verwenden sollen, stellen Sie die folgenden Fragen:

• Gibt es einen für die benutzende Person logischen oder erforderlichen nächsten Schritt? Dabei kann es sich um die nächsten benötigten Informationen oder ein Feature handeln, das sie bei der Ausführung der Aufgabe unterstützen würde.
• Gibt es einen geschäftlichen Grund, weshalb der Nutzer zu diesem Ort gesendet wird?

Ein CTA sollte nur verwendet werden, wenn die Antwort auf beide Fragen Ja lautet.

Wie unterscheidet sich ein CTA von einem Link?

Durch einen CTA wird eine benutzende Person explizit dazu angewiesen, eine sofortige Aktion wie „Teste Copilot kostenlos“ oder „Erstelle ein eigenes Repository“ auszuführen. In der Dokumentation sollte ein CTA Personen ausschließlich zu einer Domäne im Besitz von GitHub weiterleiten.

Beispiel: Der CTA Einrichten einer Testversion von GitHub Enterprise Cloud stellt einen Link zu einer Enterprise-Vertriebsseite auf GitHub.com dar.

CTAs erstellen

Um eine gültige CTA-URL mit den korrekten Parametern zu erstellen, verwende das CTA-Builderskript in „checkout“ für dein Dokumentrepository:

npm run cta-builder

Das Skript wird Sie durch einen interaktiven Prozess führen, um Folgendes zu erreichen:

• Wählen Sie das entsprechende Produkt von GitHub aus (ref_product).
  • Verwenden Sie github als Standard, wenn der Link nicht spezifisch für ein bestimmtes Feature oder Produkt ist.
• Auswählen des Aktionstyps (ref_type)
• Formatvorlage angeben (ref_style)
• Optional einen bestimmten Plan auswählen (ref_plan)

Das Skript stellt alle verfügbaren Optionen für jeden Parameter bereit und generiert am Ende eine vollständige, gültige CTA-URL. Verwenden Sie dieses Tool, um sicherzustellen, dass Sie aktuelle, genehmigte Werte für CTA-Parameter verwenden.

Beispielsweise kann das Skript eine URL wie folgt generieren:

https://github.com/account/enterprises/new?ref_product=ghec&ref_type=trial&ref_style=button&ref_plan=enterprise

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 und Formatierung von Codeblöcken finden Sie unter Verwenden von Markdown und Liquid in GitHub Docs.

Innerhalb von Codeblöcken:

• Gib die Sprache des Beispiels nach dem ersten Codeblock 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 Siegit checkout -b BRANCH-NAME * Vermeiden: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.

  •       **Verwenden:**
    

    command
    # output
    

  •       **Vermeiden:**
    

    $ command
    output
    

• Wenn dein Codebeispiel { oder } zum Rendern enthält, 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

Schließen Sie keine Eingabeaufforderungen wie $ ein. 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.

•         **Verwenden:**
  

  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. * Verwenden:

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 `.github/workflows/`-Datei in deinem Verzeichnis `example-workflow.yml`.
  

•         **Vermeiden Sie:** Erstellen Sie in Ihrem Verzeichnis _.github/workflows/_ die `example-workflow.yml`-Datei.
  

•         **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.

•         **Verwenden:**
  

    steps:
      - uses: actions/checkout@v5
      - name: Setup Python
        uses: actions/setup-python@v5
        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 Benutzerinnen Code aus der GitHub Docs kopieren, sollten wir Beispiele verwenden, die die Benutzerinnen von überlasteten Zeiten wegführen.

• 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

Heben Sie Wörter oder Teile eines Satzes per Fettformatierung hervor. Verwende Hervorhebungen sparsam (höchstens fünf zusammenhängende Wörter), und denke daran, dass dies eine visuelle Hilfe für sehende Benutzende ist.

• Fetten Sie keine Wörter, auf die andere Formatierungen angewendet werden, z. B. Großbuchstaben für Platzhaltertext.
• Verwende zur Erzielung von Barrierefreiheit die Fettformatierung nicht als einziges Mittel, um Bedeutung oder Hervorhebung zu vermitteln.

Zum Beispiel:

•         **Verwenden:** Verwaltete Benutzerkonten **können keine öffentlichen Inhalte** erstellen oder außerhalb Ihres Unternehmens zusammenarbeiten.
  

•         **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 findest du 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.

Ablaufende Inhalte

Im Allgemeinen sollten Sie keine ablaufenden Inhalte dokumentieren. Alle Besucher*innen von GitHub Docs sollten darauf vertrauen können, dass die Informationen korrekt und auf dem neuesten Stand sind.

Wenn Sie Inhalte dokumentieren müssen, von denen Sie wissen, dass sie ablaufen werden, können Sie mit dem Inhalts-Linter das Ablaufdatum der Inhalte markieren und verfolgen. Dadurch werden die Inhalte als veraltet gekennzeichnet, und die Verfolgung von Ablaufterminen außerhalb der Inhalte selbst wird vermieden. Informationen zum Formatieren von Tags für ablaufende Inhalte findest du unter Verwenden des Inhalts-Linters.

Fußnoten

Vermeide nach Möglichkeit die Verwendung von Fußnoten. Überlege stattdessen, ob du einen Warnhinweis verwenden oder die Informationen auf andere Weise darstellen könntest. 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.

          [^1]: Not to be confused with Davy Jones of The Monkees

          [^2]: Also humans

| | 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

Überschriften

Ü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.

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. * Verwenden:

## HEADER (H2)

TEXT

### SUBHEADER (H3)

TEXT

#### SUBHEADER (H4)

TEXT

•         **Vermeiden:**
  

  ## HEADER (H2)
  
  #### SUBHEADER (H4)
  

Jede Überschrift auf einer Seite muss auf derselben Ebene einzigartig sein.

•         **Verwenden:**
  

  ## Examples  (H2)
  
  TEXT
  
  ### Prompts for writing code (H3)
  
  TEXT
  
  ### Prompts for writing tests (H3)
  
  TEXT
  

•         **Verwenden:**
  

  ## Prompts for writing code (H2)
  
  TEXT
  
  ### Example (H3)
  
  TEXT
  
  ## Prompts for writing tests (H2)
  
  TEXT
  
  ### Example (H3)
  
  TEXT
  

•         **Vermeiden:**
  

  ## Example prompts (H2)
  
  TEXT
  
  ### Example (H3)
  
  TEXT
  
  ### Example (H3)
  
  TEXT
  

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.
• Mit einem Satzzeichen beenden. 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 ...“. Bildschirmlesegeräte sagen dies 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 im begleitenden Artikeltext enthalten sein.

Format

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

• Verwende für Product name den Namen des GitHub-Produkts oder der -Funktion, zum Beispiel GitHub Actions oder GitHub-Repository, 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 und Grafiken

Erkläre die Informationen, die im Diagramm oder Graph 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.

Beispielsweise finden Sie eine begleitende Erklärung zu diesem Diagramm in der Dokumentation zu Aktionen.

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 Siedata-pack-purchase-button.png * Vermeiden:purchase_button.png * Vermeiden:purchase-button.png

Bildschirmfotos

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

Diagramme

Weitere Informationen zum Erstellen von Diagrammen findest du 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 Wörter, die inklusiv, antirassistisch und zugänglich 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.

Ressourcen zu inklusiver Sprache

Der Microsoft-Styleguide enthält Ressourcen zu unvoreingenommener Kommunikation, zugänglichen Begriffen und Schreiben, das alle Fähigkeiten berücksichtigt: * Unvoreingenommene Kommunikation * Schreiben für alle Fähigkeiten * Barrierefreiheitsbegriffe

Weitere Ressourcen zu inklusiver und zugänglicher Sprache und Stil:

• Styleguide von MailChimp: * Schreiben über Personen * Schreiben für Barrierefreiheit

•         [Richtlinien zur Lesbarkeit](https://readabilityguidelines.co.uk/)
  

•         [Styleguide für bewusste Sprache](https://consciousstyleguide.com/)
  

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 Sie**`<kbd>Command</kbd>+<kbd>B</kbd>`
    

  •       **Vermeiden:**`Command+B`
    

• Verwende ganze Wörter anstelle von Symbolen für Apple-Zusatztasten.

  •       **Verwenden Sie**`Command`
    

  •       **Vermeiden:**`⌘`
    

• Verwende Symbole für Tasten mit Sonderzeichen, keine ganzen Wörter.

  •       **Verwenden:**`.`, `,` und `→`
    

  •       **Vermeiden:**`Period`, `Comma` und `Right arrow`
    

Nutzungshighlights

Hier sind einige Nutzungshinweise, wie wir Tastenkombinationen in unserer Dokumentation präsentieren.

• Die grundlegende Syntax besteht darin, Tastenkombinationen mit + zwischen den Tasten und ohne Leerzeichen anzugeben.

  •       **Verwendung:**`<kbd>Command</kbd>+<kbd>B</kbd>`, das als <kbd>Befehl</kbd>+<kbd>B</kbd> gerendert wird.
    

  •       **Vermeiden Sie:**`<kbd>Command</kbd> + <kbd>B</kbd>` oder `<kbd>Command + B</kbd>`, da sie als <kbd>Befehl</kbd> + <kbd>B</kbd> oder <kbd>Befehl + B</kbd> gerendert werden
    

• Schreib Buchstaben für allgemeine Verweise und Tastenkombinationen immer groß.

  •       **Verwenden:**<kbd>Befehl</kbd>+<kbd>B</kbd>
    

  •       **Vermeiden:**<kbd>Command</kbd>+<kbd>b</kbd>
    

• Verwende die richtigen Zusatztasten für jedes Betriebssystem.

          **Hinweis:** Unter Windows und Linux wird <kbd>STRG</kbd> abgekürzt, während es unter Mac ausgeschrieben wird: <kbd>Control</kbd>.
  

  • Für Windows und Linux:

    •     **Verwenden:**<kbd>STRG</kbd>, <kbd>ALT</kbd>
      

    •     **Vermeiden:**<kbd>Kontrolle</kbd>
      

  • Für Mac:

    •     **Verwenden:**<kbd>Command</kbd>, <kbd>Option</kbd>, <kbd>Control</kbd>
      

    •     **Vermeiden:**<kbd>Cmd</kbd>, <kbd>⌘</kbd>, <kbd>Opt</kbd>, <kbd>⌥</kbd>, <kbd>Ctrl</kbd>, <kbd>⌃</kbd>
      

• Verwechsle Tastenkombinationen nicht mit Tastenabfolgen.

  •       <kbd>Befehl</kbd>+<kbd>B</kbd> bedeutet, dass Benutzer*innen die <kbd>Befehl</kbd>-Taste gedrückt halten und dann die <kbd>B</kbd>-Taste drücken sollen.
    

  •       <kbd>G</kbd><kbd>I</kbd> bedeutet, dass Benutzer*innen zuerst die <kbd>G</kbd>-Taste und dann die <kbd>I</kbd>-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:
    
    
          <kbd>BEFEHL</kbd>+<kbd>B</kbd> (Mac) oder <kbd>STRG</kbd>+<kbd>B</kbd> (Windows/Linux)
    

  •       **Vermeiden:**`<kbd>Ctrl</kbd>+<kbd>B</kbd> or <kbd>Command</kbd>+<kbd>B</kbd>`, dargestellt als:
    
    
          <kbd>STRG</kbd>+<kbd>B</kbd> oder <kbd>BEFEHL</kbd>+<kbd>B</kbd>
    

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 Elemente für Lizenzangaben. 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 hier 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

Links werden verwendet, um Personen mit zusätzlichen Informationen zu verbinden und Aufgaben zu durchlaufen, für die mehrere Artikel gelesen werden müssen.

          **Gehen Sie sparsam mit Links um** Zu viele Links können vom Hauptinhalt ablenken oder den Fokus der Benutzer stehlen. Alle Links sollten im Kontext der User Journey berücksichtigt werden: Warum verweisen wir jemanden an diesen Link und wie können wir die Personen wieder auf den Weg bringen, um ihre Aufgabe abzuschließen?

Bevor Sie einen Link hinzufügen, entscheiden Sie, ob jemand den Link aufrufen muss, um den Inhalt zu verstehen oder GitHub erfolgreich zu verwenden.

• Wenn der Link nicht erforderlich ist, entfernen Sie ihn.
• Wenn sich der Link auf das Hauptthema eines Artikels bezieht und jemandem beim Lernen hilft, aber nicht erforderlich ist, um die Aufgabe abzuschließen, erwägen Sie, den Link an das Ende des Artikels für weitere Informationen zu verschieben.
• Wenn der Link jemanden zum nächsten Schritt in einem Prozess führt, fügen Sie den Link in einen Abschnitt mit den nächsten Schritten am Ende des Artikels ein.
• Wenn der Link Informationen bereitstellt, die für das Ausführen einer Aufgabe oder die Problembehandlung eines Schritts von entscheidender Bedeutung sein können, schließen Sie den Link in den Haupttext des Artikels ein.

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.

Einige Best Practices für die Verwendung von Links:

• Links sollten aussagekräftig sein und nützlich für die User Journey sein. Nutzen Sie Links mit Bedacht.
• Wiederholen Sie einen Link nicht mehrmals im selben Artikel.
• Erwägen Sie, „früher/später in diesem Artikel“ nach einem Link zu einem Abschnitt im selben Artikel hinzuzufügen.
• Schließen Sie den Abfrageparameter apiVersion nicht in REST-Links ein, es sei denn, Sie müssen einen Link zu einer bestimmten Kalenderversion der REST-Dokumentation angeben. (Das sollte selten vorkommen.)

Links formatieren

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.

Wende keine Formatierung auf Verknüpfungen an bzw. umschließe sie nicht in Anführungszeichen.

• 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).

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 zu lesen sein.

Füge keine Interpunktionszeichen in einen Hyperlink ein.

•         **Verwenden Sie**`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:**`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.`
  

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

Links zu bestimmten Abschnitten von Artikeln müssen so ausführlich sein, dass jemand versteht, dass er sich nach dem Folgen eines Links an der richtigen Stelle befindet.

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

For more information, see [HEADER TITLE](#HEADER-TITLE), later in this article.

Links zu Abschnitten auf derselben Seite funktionieren nicht mit AUTOTITLE. Geben Sie stattdessen den vollständigen Überschriftentext ein:

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 Sie mit einem bestimmten Tool auf Inhalte verweisen, stellen Sie sicher, dass der Link für ein bestimmtes Tool bestimmt ist, auch wenn jemand nicht mit der Registerkarte „Toolumschalter“ im Artikel interagiert.

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

Wenn Sie eine Verknüpfung mit einer externen Website herstellen, wählen Sie 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 oder eine bestimmte Seite handelt, wenn dies hilfreicher wäre.

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

Geben Sie für Links zu einer externen Seite (jede Website, die nicht von GitHub verwaltet wird) den vollständigen Seitentitel und die Zielwebsite ein. Setzen Sie den Link nicht in Anführungszeichen.

•         **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).`
  

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.

<!-- Anchor to maintain the current example link. -->
<a name="SECTION-TITLE-THAT-MIGHT-CHANGE"></a>

Listen

Schreibe den ersten Buchstaben 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).
• Verwenden Sie Sternchen (*) für Listenelemente.

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.

          **Verwenden:**

• 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:

Berechtigungserklärungen und Produktankündigungen

Verwenden Sie Berechtigungsanweisungen und Produktaufrufe, um Aufgaben zu beschreiben, für die bestimmte Rollen oder Produkte erforderlich sind.

•         [
          **Berechtigungsanweisungen**](/contributing/style-guide-and-content-model/contents-of-a-github-docs-article#permissions-statements): Die Rolle, die erforderlich ist, um eine Aktion auszuführen oder eine im Artikel beschriebene Aufgabe auszuführen. Beispiel: „Unternehmensbesitzer“.
  

•         [
          **Produkthinweis**](/contributing/style-guide-and-content-model/contents-of-a-github-docs-article#product-callout): Das Produkt oder die Produkte, die benötigt werden, um eine im Artikel beschriebene Aktion oder Aufgabe auszuführen. Beispiel: „Organisations- oder Unternehmenskonto mit einem Abonnement für Copilot Business.“
  

Zusammen teilen Berechtigungsanweisungen und Produkthinweise Lesern mit, wer das Feature verwenden kann, das in einem Artikel beschrieben wird.

Richtlinien zum Erstellen von scanbaren Produkthinweisen

Definieren von Berechtigungen im Vergleich zu Produktanforderungen

Überlegen Sie, welche Informationen in einer Berechtigungserklärung oder einen Produkthinweis gehören.

Wenn du beispielsweise Berechtigungen und Produkthinweise für den Artikel Verwalten von Richtlinien und Features für GitHub Copilot in Ihrer Organisation erstellst, würde die Berechtigungserklärung die Frage beantworten: „Welche Rolle ist für die Verwaltung von Richtlinien und Features für GitHub Copilot in einer Organisation zuständig?“ Und der Produkthinweis würde folgende Frage beantworten: „Welche Copilot-Abonnements benötigen Benutzer, um Copilot-Richtlinien und -Features für eine Organisation zu verwalten?"

Konzentrieren Sie sich auf wichtige Informationen, keine Erklärungen

Berechtigungsanweisungen und Produkthinweise müssen kommunizieren, wer eine Aufgabe ausführen kann und welches Produkt erforderlich ist. Sie müssen nicht erklären, warum eine Rolle oder ein Produkt erforderlich ist.

Wenn mehrere Rollen oder Produkte auf eine Berechtigungsanweisung oder einen Produkthinweis angewendet werden, formatieren Sie sie mithilfe einer nicht ungeordneten Liste. Sie können komplexe Berechtigungsanweisungen und Produkthinweise mit einem Satz einführen, aber immer versuchen, so wenige Wörter wie nötig zu verwenden, um zu kommunizieren, wer das Thema des Artikel ausführen kann.

Verwenden von Inline-Links

Sie können Inline-Links verwenden, um weitere Informationen zu einer Rolle oder einem Produkt bereitzustellen. Der verknüpfte Text muss mit dem Link-Ziel übereinstimmen, sodass klar ist, wohin der Link führt.

Platzhalter

Formatieren Sie jeden 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.

          **Verwenden:**

• 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.

Verfahrensschritte

Abläufe veranschaulichen den Leser*innen eine Reihe aufeinanderfolgender Schritte, die zum Ausüben einer Aufgabe erfolgen müssen. Verwenden für Abläufe immer nummerierte Listen. Vermitteln Sie den Lesern vorab alle Voraussetzungen oder Informationen konzeptioneller Art, die sie für die Aufgabe benötigen, anstatt sie in einen bestimmten Schritt zu integrieren.

Jeder Schritt muss eine Aktion enthalten. Sie können 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 Sie beschreiben, wo die Aktion stattfinden muss, bevor Sie sie anleiten, die Aktion auszuführen.

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

1. Wenn der Schritt optional ist, gib diese Information zuerst an.

2. 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.

3. Beschreiben Sie, wo die Benutzer*innen die Aktion finden.

4. Action (Aktion).

          **Verwenden:** Optional kannst du für `REASON` in `LOCATION` die Aktion `ACTION` ausfü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 Variablen für Produktnamen, um Produktnamen zu rendern. Schreiben Sie Produktnamen nicht als Klartext. 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ützet dich beim Automatisieren deiner Softwareentwicklungsworkflows.

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

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 Komponenten 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 Aktionen befinden sich in /data/reusables/actions/ und haben einen Dateinamen wie action-<action_name>.md

Um die Aktion actions/checkout in einem Beispiel zu verwenden, nutzen Sie deren Wiederverwendbarkeit:

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

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@v5

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 %}, 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.

Festlegen von Versionsnummern für 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 Sie immer „dev container“ (oder, falls eine Erklärung notwendig ist, die längere Form „Entwicklungscontainer“) und nicht „devcontainer“ (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 compose.yaml-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-Produkte (GHAS)

Verwende die Begriffe licenses und active committers, wenn du dich auf die Abrechnung von GitHub Advanced Security, GitHub Code Security oder GitHub Secret Protection beziehst.

Wir haben den Begriff seats verwendet, um die Anzahl der Konten zu beschreiben, die GitHub Advanced Security, GitHub Code Security oder GitHub Secret Protection 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 (classic): 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 im Titelstil („Personal Access Token“) geschrieben werden soll, um sich an den Text auf der Benutzeroberfläche anzupassen.
• 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 (classic) zu verweisen.

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

Interpunktion

Befolgen Sie außerdem die üblichen deutschen Interpunktionsregeln. Weitere Informationen finden Sie 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 finden Sie unter Inhaltstyp der Versionshinweise.

Jeder Versionshinweis beschreibt eine der folgenden Änderungen.

•         [Features](#features): brandneues Verhalten oder neue Funktionalität
  

•         [Sicherheitskorrekturen](#security-fixes): Fixes für Risiken oder unerwartetes Verhalten mit Auswirkungen auf die Sicherheit
  

•         [Fehlerbehebungen](#bug-fixes): Fixes für Fehler oder unerwartetes Verhalten
  

•         [Änderungen](#changes): wichtige Änderungen am bisherigen Verhalten
  

•         [Bekannte Probleme](#known-issues): Probleme, die von GitHub erkannt wurden, jedoch nicht priorisiert werden können oder noch nicht priorisiert wurden
  

•         [Wird eingestellt](#closing-down): Prozess der Einstellung; sollte für zukünftige Arbeiten nicht mehr verwendet werden.
  

•         [Eingestellt](#retired): Ende des Lebenszyklus eines Produkts oder einer Funktion
  

•         [Errata](#errata): Korrektur an ungenauen Versionshinweisen oder Dokumentationen
  

Die Richtlinien zum Aktualisieren von Versionshinweisen findest du auch unter Hinzufügen oder Aktualisieren von Versionshinweisen und Entfernen eines Versionshinweises.

Funktionen

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:

1. Gilt dieses neue Feature für mich (mit meiner Rolle oder meinen Zugriffsberechtigungen)?
2. Welchem Zweck dient das Feature?
3. Was ist die Funktionalität?
4. Wo kann ich ggf. mehr über das Feature erfahren?

          _ZIELGRUPPE_ (**1**) kann _BESCHREIBUNG DER NOTWENDIGKEIT_ (**2**) durch _BESCHREIBUNG DER FUNKTIONSVERWENDUNG_ (**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, an welchen Orten Benutzerinnen Repositorys abzweigen können. Das Forken kann auf voreingestellte Kombinationen aus Organisationen, die gleiche Organisation wie das übergeordnete Repository, Benutzerkonten oder überall 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

Ein Versionshinweis für einen Sicherheitsfix beantwortet die folgenden Fragen.

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

          _SCHWEREGRAD_ (**1**): Ein Angreifer 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](https://bounty.github.com) (**5**) gemeldet wurde.

Beispiele für Versionshinweise für Sicherheitsfixes

•         **MITTEL**: Ein*e Angreifer*in 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](https://github.com/gjtorikian/commonmarker) aktualisiert. GitHub hat für dieses Sicherheitsrisiko die [CVE-ID CVE-2022-39209](https://nvd.nist.gov/vuln/detail/CVE-2022-39209) beantragt.
  

•         **MITTEL**: Ein*e Angreifer*in 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](https://bounty.github.com) 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 Hinweise für Fehlerbehebungen nur in Patch-Releases enthalten.

Schreiben von Releasenotes für Bugfixes

Versionshinweise für eine Fehlerbehebung beantworten die folgenden Fragen:

1. War ich (mit meiner Rolle oder meinen Zugriffsberechtigungen) von diesem Verhalten betroffen?
2. 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, formatiere 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 bemerkenswerte, aber geringfügige Änderung des bestehenden Verhaltens beschrieben. Notizen zu Änderungen beantworten die folgenden Fragen.

Schreiben von Versionshinweisen für Änderungen

Versionshinweise für Änderungen beantworten die folgenden Fragen:

1. War ich (mit meiner Rolle oder meinen Zugriffsberechtigungen) von diesem Verhalten betroffen?
2. Welches Problem wird durch die Änderung behoben oder vermieden?
3. Was ist das neue Verhalten?
4. 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 Lizenz für GitHub Advanced Security oder GitHub Secret Protection können Benutzende, 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 müssen. Diese Grenze wurde von 1.000 Zeichen erhöht.

• 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 Befehlszeilen-Hilfsprogramme.

• 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:

1. Bin ich (mit meiner Rolle oder meinen Zugriffsberechtigungen) von diesem Verhalten betroffen?
2. Welche Fehlermeldungen oder sonstigen erkennbaren Benutzeroberflächenelemente werden angezeigt?
3. Muss ich Maßnahmen ergreifen? Was soll ich tun?

          _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, formatiere die Nachricht gemäß der Anleitung unter Fehlermeldungen.
• Füge ggf. relevante Links zur GitHub-Dokumentation ein.
• Bekannte Probleme sind auch eine Inhaltskategorie auf GitHub Docs. Weitere Informationen findest du unter Inhaltstyp zur Problembehandlung. Wenn es hilfreich ist, schreiben Sie oder verlinken Sie auf ausführlichere und in Bezug stehende Inhalte in den Unterlagen.

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.

In Einstellung begriffen

Ein Versionshinweis für ein Feature, das eingestellt wird, enthält die Zusammenfassung eines Verhaltens oder Features, dessen Entfernung von GitHub geplant ist. Diese Features sind weiterhin für den Produktionseinsatz verfügbar und es gelten nach wie vor die entsprechenden Support-SLAs und technischen Supportverpflichtungen. Sie werden jedoch derzeit stillgelegt und sollten für zukünftige Arbeiten nicht mehr verwendet werden. Der Begriff „Abschaltung“ beschreibt eine Übergangsphase, in der den Benutzern empfohlen wird, die Nutzung des Features einzustellen und sich auf die Abschaltung vorzubereiten.

Schreiben von Versionshinweisen für Funktionen, die eingestellt werden

Ein Versionshinweis für ein Feature, das eingestellt wird, beantwortet die folgenden Fragen.

1. Gilt das bisherige Feature für mich (mit meiner Rolle oder meinen Zugriffsberechtigungen)?
2. Welche Funktionalität wird eingestellt?
3. Wodurch wird die stillgelegte Funktionalität gegebenenfalls ersetzt?
4. Wo finde ich ggf. weitere Informationen?

          _ZIELGRUPPE_ (**1**) _BESCHREIBUNG DER FUNKTIONALITÄT, DIE EINGESTELLT WIRD_ (**2**) _ERSATZFUNKTIONALITÄT_ (**3**) Weitere Informationen findest du unter [_ARTIKELTITEL_](/) (**4**).

• Diese Versionshinweise werden im Präsens oder für bevorstehende Änderungen im Futur verfasst. Gib das bevorstehende Release an, in dem die Einstellung stattfinden wird, wenn anwendbar.
• 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 Features, die eingestellt werden

•         **Wird eingestellt:** 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 Timeline-Ereignisse und das PullRequest-Objekt der GraphQL-API geben ebenfalls keine Commit-Kommentare mehr zurück.

Zurückgezogen

Eingestellte Produkte oder Funktionen sind für neue Kunden nicht mehr verfügbar und werden nicht mehr vermarktet, unterstützt oder dokumentiert. In dieser Phase wird das Produkt effektiv eingestellt, und es werden keine neuen Entwicklungen oder Korrekturen mehr bereitgestellt. Die einzige Unterstützung für eingestellte Produkte kann aus bestehenden Verpflichtungen herrühren, wie sie z. B. die für zuvor veröffentlichte Versionen von GitHub Enterprise Server erforderlich waren. Die Abkündigung markiert das offizielle Ende des Lebenszyklus eines Produkts oder Features, ohne weitere Updates, Fehlerbehebungen oder Support, und signalisiert eine vollständige Umstellung auf neuere Werkzeuge oder Dienste.

Schreiben von Versionshinweisen für eingestellte Funktionen

Ein Versionshinweis für ein eingestelltes Feature beantwortet die folgenden Fragen.

1. Betrifft diese Funktionalität mich, meine Rolle oder meinen Zugriff?
2. Welche Funktionalität wird eingestellt?
3. Wodurch wird die eingestellte Funktionalität ggf. ersetzt?
4. Wo finde ich ggf. weitere Informationen?

          _ZIELGRUPPE_ (**1**) _BESCHREIBUNG DER FUNKTIONALITÄT, DIE EINGESTELLT WIRD_ (**2**) _ERSATZFUNKTIONALITÄT_ (**3**) Weitere Informationen findest du unter [_ARTIKELTITEL_](/) (**4**).

• Die Hinweise werden im Präsens geschrieben.
• 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 eingestellte Features

•         **Eingestellt:**: GitHub unterstützt die erforderlichen Workflows für GitHub Actions in GitHub Enterprise Server 3.11 und höher nicht mehr. Verwenden Sie stattdessen Repositoryregelsätze. Weitere Informationen finden Sie unter [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging).
  

Korrigenda

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

Errata schreiben

Errata beantwortet die folgenden Fragen:

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

          _INHALT_ (**1**) hat fälschlicherweise ausgesagt, dass _ZIELGRUPPE_ (**2**) _ZUSAMMENFASSUNG FALSCHER INFORMATIONEN_ (**3**) kann. [Aktualisiert: _VERÖFFENTLICHUNGSDATUM_**4**]

• 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 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.

Entfernen eines Versionshinweises

Um zu signalisieren, dass wir einen Versionshinweis entfernt haben, fügen Sie einen Abschnitt „Errata“ hinzu, in dem angegeben wird, welchen Hinweis Sie entfernt haben und (falls relevant) welche Version der entfernte Hinweis tatsächlich betrifft. Siehe Errata verfassen.

Versionsverweise

Wenn du auf eine Reihe von Releases verweist, die ab einem bestimmten Release beginnen, verwende „oder später“.

•         **Verwende:** „Release 0.41.0 oder später“
  

•         **Vermeide:** „Version 0.41.0 oder höher“
  

•         **Vermeide:** „Release 0.41.0 oder höher“
  

Wiederverwendbare Elemente 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 findest du im Datenverzeichnis im Repository github/docs unter Erstellen wiederverwendbarer Inhalte und im Abschnitt Produktnamen dieses Dokuments.

Abschnitts-Inhaltsverzeichnisse

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 Leser*innen zu helfen, die für sie relevanten Informationen zu erkennen und zu diesen zu navigieren. Beispielsweise richten die Leser von Streaming des Überwachungsprotokolls für Ihre Organisation 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 Leser von Grundlagen der 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 Leserinnen jeden Abschnitt durchlesen und nicht zwischen diesen auswählen sollen. Das Hinzufügen eines Abschnittsverzeichnisses würde auch Personen, die Bildschirmlesegeräte oder andere adaptive Technologien verwenden, zwingen, durch mehr Überschriften zu navigieren, bevor sie die benötigten Informationen finden.

Formatiere Abschnitts-Inhaltsverzeichnisse 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 Abschnittsinhaltsverzeichnisse

## 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.

Vermeide das Beschreiben von Tabellendaten

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 Referenzen zu 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.

Um Zeilenüberschriften für eine Markdowntabelle hinzuzufügen, umschließe die Tabelle mit den Liquid-Tags {% rowheaders %} {% endrowheaders %}. Weitere Informationen zur Verwendung von Zeilenüberschriften findest du 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

Weitere Informationen findest du in den Fußnoten.

Richte die Tabelleninhalte konsistent 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 Referenz zu Dependabot-Optionen.

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 die Großschreibungsregel für Sätze für Titel.

Kurztitel

Wir verwenden Kurztitel für die Seitenleisten-Navigation. 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 Grundform von Verben anstelle von Gerundien. * Verwenden: "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: „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 sollten parallel zu Kurztiteln für ähnliche Inhalte formuliert sein. * Verwenden: "Organisationen und Teams" und "Unternehmenskonten" * Vermeiden: "Organisationen und Teams" und "Verwalten von Unternehmenskonten"

Das Schreiben von Kurztiteln kann schwierig sein. Um Kurztitel innerhalb der Zeichenbegrenzung zu erhalten, sollten Sie den Kurztitel im Kontext betrachten. 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

Fettschrift

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 der Kontrollkästchen fett und lass das Wort „Kontrollkästchen“ weg. Verwende „aktivieren“ oder „deaktivieren“, um das Aktivieren oder Deaktivieren eines Kontrollkästchens zu beschreiben. * Verwendung: Wählen Sie Für alle neuen Repositories aktivieren aus. * 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. * Anleitung: Klicke auf BENUTZERNAME zu REPONAME 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

Gemäß WCAG-Leitfaden sollten Elemente anhand des Namens und nicht nur anhand des Erscheinungsbilds oder der Position beschrieben werden. Der Microsoft-Styleguide enthält genaue Anweisungen für direktionale Ausdrücke mit Schwerpunkt auf deren Verwendung in der Dokumentation.

•         [über](https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/a/above) oder [unter](https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/b/below)
  

•         [oben links, oben rechts](https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/u/upper-left-upper-right)
  

•         [unten links, unten rechts](https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/l/lower-left-lower-right)
  

• Neben der Seite, unten oder oben auf der Seite, links oder rechts auf der Seite

Paneele

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. * Vermeiden: Klicke auf Diagramme anzeigen, um das Panel für dein ausgewähltes Repository zu öffnen, wähle dann im Dropdown-Menü 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

Verwenden Sie Backticks, um Repository-Namen in Monospace-Schrift zu formatieren. 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. Platziere sämtliche Kommas außerhalb der Anführungszeichen.

•         **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 finden Sie 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: Administratoren

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 Typen 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.

•         **Verwalten:** Geplante Erinnerungen für dein persönliches Konto verwalten
  

•         **Vermeiden:** Verwalten geplanter Erinnerungen für dein Benutzerkonto
  

Konten für Enterprise-Produkte

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.

•         [GitHub Enterprise Cloud](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
  

•           [GitHub Enterprise Server](/enterprise-server@latest/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
  

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. Abrechnung für GitHub Enterprise
• Inhalte in weiteren Produkten, die für die Administration bestimmt sind, z. B. Bewährte Methoden zum Schützen von Konten im Produkt „Schreiben von sicherem Code“ oder Einrichten einer Testversion von GitHub Enterprise Cloud im Produkt „Erste Schritte“
• Unternehmensspezifische API-Inhalte, z. B. die REST-API-Referenzdokumentation REST-API-Endpunkte für GitHub Unternehmensverwaltung

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 von Nutzern 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. * Verwendung: Veröffentlichen und Listen Sie Ihre App im GitHub Marketplace

Verwende „App“, wenn du auf OAuth apps verweist, da es sich hierbei nicht um ein Produkt handelt. * Verwenden: Registriere eine OAuth app * Vermeiden: Registrieren einer OAuth-App

Verwende „App“, wenn du auf GitHub Apps verweist, da es sich hierbei um ein Produkt handelt. * Verwendung: Registrierung 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. * Verwendung: Registrierung 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“. * Verwendung: Code für deine App * Verwende: Code für deine GitHub App * Verwenden: den Code Ihrer 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.

Verwenden Sie Kleinbuchstaben für Währungsbezeichnungen, aber schreiben Sie die Bezeichnung des Landes oder der Region groß. * Verwendung: US-Dollar * Vermeiden: US-Dollar, $USD-Dollar.

Verwende Großbuchstaben für Währungscodes. * Verwendung: 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 Erwähnungen. * 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, ist das Herkunftsland oder die Region der Währung in Klammern unmittelbar nach der ersten Erwähnung in Großbuchstaben anzugeben. 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 Erwähnungen.
  

•         **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. Organisationseigentümer, Abrechnungsmanager für Unternehmenskonten)
• 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 eines Teams auf die Repositorys deiner Organisation
  

•         **Verwenden:** Wenn Ihre Teammitgliedschaft Ihnen einen anderen Zugriffsumfang bietet als Ihre Rolle als Organisationsbesitzer ...
  

•         **Verwenden:** Personen mit Schreibzugriff können ...
  

•         **Vermeiden:** Personen mit 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, außer der Satz würde sonst merkwürdig oder zu formell klingen.

Produktnamen

Weitere Informationen findest du im Abschnitt Produktnamen dieses Leitfadens.

Zu verwendende oder vermeidende Begriffe

Wortwahl

Mehrdeutige Verben

Wenn eine Aufgabe erforderlich ist oder eine Option einer anderen bevorzugt wird, vermeiden Sie die Verwendung von mehrdeutigen modalen Hilfsverben wie „kann“, „könnte“, „soll“, „sollte“, „dürfte“, „möchte“ 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 den Zweig löschen.
  

Unsichtbare Plurale

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.
  

Reihen von Nomen

Vermeide aneinandergereihte Modifikatoren (Reihen von Substantiven), da sie zu Fehlübersetzungen führen können, weil die Übersetzer nicht bestimmen können, welches Wort das andere modifiziert. Formuliere die Nomenkette mithilfe von Präpositionen um. Falls die Verwendung eines gestapelten Modifikators unerlässlich ist, sollten Sie sicherstellen, dass die Hintergrundinformationen und der Kontext klar sind, damit Leserinnen und Übersetzerinnen verstehen, was modifiziert wird. * Verwenden: Standardeinstellungen der Quelle für öffentliche Repositories * 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 du den letzten Commit für deine Verzweigung ausgeführt und deine Pullanforderung zusammengeführt hast, kannst du dies löschen.