Create npm-grunt.yml

[TheodorvonHaft]

Skills
GitHub Skills Quickstart Guide
Build your own GitHub Actions-powered courses in a few simple steps.

This guide covers planning your course, building your course, and best practices for GitHub Actions-powered courses.

Take a look at our GitHub Skills courses for examples and templates.

Table of contents
Author prerequisites
Planning your course
Set up your repository
Writing your README
Writing your Actions workflow files
Testing and monitoring your course
Best practices for building courses
Author prerequisites
Course authors should be familiar with Markdown, YAML, and GitHub Actions before starting to make their own courses.

Some courses will require knowledge of GitHub CLI and command line.

Planning your course
Write down your learning goals
Does your course give the learner something practical to work on?
Learners prefer working on real projects over examples.
How can the learner use this project after they finish the course?
What specific skill does the learner leave your course with?
Focus on what the learner will be able to do after they complete the course.
Is an Actions-based course right for your goal?
Does the learning experience benefit from step-by-step, in-repository learning?
Outline your steps
Does this workflow match what the learner will do in the “real world”?
If you were teaching your friend, how would you interact with them in the repository?
Does each step build towards the skills you’ve identified?
Can you teach the skill in three to five small steps?
Most learners tend to drop off after 30-45 minutes.
We’ve found that it takes learners about four times the length of an expert to complete a course.
If your course needs more steps, consider splitting your learning objective into multiple courses.
Does the order of the steps build the learner’s knowledge in each step?
Each step should reference and build on the knowledge in the previous steps.
Does each step relate to the main learning goal?
You can use GitHub Actions and GitHub CLI to automate any needed steps that don’t build towards the learning goal.
Set up your repository
Start by clicking “Use this template” on our course template.
Check the box for “Template repository” either when setting up your repository, or in the repository settings afterwards. Actions are not enabled by default in forks.
Add a 1280×640 social image. Learners will share your course on different websites that will pull in the social image.
Enable the automatically delete head branches setting.
Add a LICENSE file to your repository.
Add a .gitignore file. You can see an example .gitignore. We recommend at minimum ignoring operating system generated files.
Include skills-course in the repository topics.
Writing your README
Your README file will have a few sections: a header, a start step, three to five workflow steps, a finish step, and a footer.

The raw source of the README in Introduction to GitHub includes many comments you can use to guide the development of your course’s README file.

Writing your README: Header
Start with a short paragraph describing what you’ll teach. Be sure to include information on how the course is relevant to the learner. This paragraph should answer the question, “Why should I take this course?”

Include the course title in sentence case, and a concise description in emphasis.

Writing your README: Start
A brief paragraph should describe the goal of the course, what the learner will learn, and why they should take the course.

A brief list of the following items can help the learner decide if the course is right for them:

Who is this for
What you’ll learn
What you’ll build
Prerequisites
How long the course is (time and steps)
Include clear directions on how to start the course.

Writing your README: Steps
Each step should:

Acknowledge the learner completed the previous step, using emphasis (italics).
Concisely describe the concept behind the next step. Link to GitHub docs for more in-depth explanation.
Describe what the learner is about to do
Mark the activity with ### ⌨️ Activity: Specific description
Use an ordered list to briefly describe what the learner needs to do
Let the learner know it will need about 20 seconds and refresh to move on to the next step
Include warning and troubleshooting information if the learner gets stuck
Try to keep your formatting consistent so the learner can more easily find what they are looking for.

The first step is the hardest, so pick something easy! On the first step, encourage users to open new tabs for steps.

Writing your README: Finish
In the finish section,

Celebrate that the learner finished the course
Include an celebratory image
Review what the learner just did
Provide next steps for learners who want to know more
Invite feedback about the course
Writing your README: Footer
Include a link for how learners should get help if they get stuck or have further questions
Include a link to the GitHub status page. If GitHub Actions is down, the course won’t work.
Include copyright information and a link to the license
Include Code of Conduct and other contributing information
The footer should not be included in the finish section. The footer should appear regardless of which step the learner is currently on.

Writing your Actions workflow files
Writing your Actions workflow files: Connect your steps to GitHub Actions events
Every step will have an Actions workflow file that triggers on GitHub Actions events. Start by reviewing which event corresponds with each of your steps.

Writing your Actions workflow files: Identify what GitHub Actions will need to do in each step
You can use GitHub CLI in your Actions workflows to perform almost any GitHub interaction you can think of. Write down everything each step will need to do to complete the step. Store links for reference as your work on your course.

Writing your Actions workflow files: Sections of the workflow file
Take a look at Introduction to GitHub for example workflow files.

Each workflow file has the name format: N-brief-summary.yml, where N is the step number and brief-summary describes the step. We recommend this format to make it easy to see the order the steps will run in.

Each workflow file will have a few sections, the name, describing comments, event trigger, job header, and steps.

The first section is the name:

name: Step 0, Start
Next, add comments describing what the Actions workflow will do:

This step triggers after the learner creates a new repository from the template.

This step updates from step 1 to step 2.

Followed by the event trigger:

This will run every time we create push a commit to main.

Reference: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows

on:
workflow_dispatch:
push:
branches:
- main
Next is the job header. You can add if tags to limit the scope of the event trigger here. You’ll also need to specify runs-on to get your Actions workflow running.

jobs:
on_start:
name: On start

# We will only run this action when:
# 1. This repository isn't the template repository.
# Reference https://docs.github.com/en/actions/learn-github-actions/contexts
# Reference https://docs.github.com/en/actions/learn-github-actions/expressions
if: ${{ !github.event.repository.is_template }}}

# We'll run Ubuntu for performance instead of Mac or Windows.
runs-on: ubuntu-latest

Last, we are finally in the steps of the Actions workflow. This is the heart of the file, where you can customize your course the most.

steps:
  # We'll need to check out the repository so that we can edit the README.
  - name: Checkout
    uses: actions/checkout@v3

  # Update README and set step to '1'.
  - name: Update to step 1
    uses: skills/action-update-step@v2
    with:
      token: ${{ secrets.GITHUB_TOKEN }}
      from_step: 0
      to_step: 1
      branch_name: my-first-branch

You may include the update step action in your course, however it is not fully required. You may also customize this script to meet the needs of your course.

Include thorough comments in your workflow files to describe each section. Other authors and your future self will thank you later.

Testing and monitoring your course
Click on “Use this template” and run through your course on a your personal account. Does everything work? Do any actions go red?
Consider asking for both technical and content review.
Test your course with a potential learner.
Check in our your course regularly for any reported issues or out-of-date information.
Best practices for building courses
Not everyone reads docs! Many potential course authors will use your course as an example. Make sure to include lots of comments in your README and Actions workflow files.
Keep everything you need in the one course repository.
If you need your courses to have limited access, create an organization for your courses, make your courses private, and invite the specific users that need these courses to your organization.
Consider adding a Code of Conduct, contributing guide, and issue templates.
Keep the number of files and folders in the root directory short. More items in the root level means the README is further down the page.
Content
The more content you have, the more content you will have to update later. Be concise. Link to the GitHub Docs whenever you can.
Where does the learner go to get help? Add links to your README to let the learner know where to ask for help.
Make it as easy as possible for the learner to get started. Learners will give up if they don’t make some progress within a few minutes.
Write in casual, polite, active, and inspiring language. We’ve found courses perform better when they are more friendly.
Use emoji to convey a positive tone. Emoji can add to content, but use words to convey meaning.
Check spelling and grammar.
Limit use of acronyms, write out the full text instead.
Images can be helpful, but only when they are up-to-date.
Provide examples and templates to reduce how much work the learner needs to do to complete the step.
Follow the GitHub docs content style guide.
Actions workflows
You can do anything in your course that GitHub Actions can do. Review the GitHub Actions docs and some examples of GitHub Actions to get a feel for what all actions can do.
If you are building a course for your own organization, you can add your own analytics or learning management system integration as part of the Actions workflows.
Sharing your course
Your course only matters if potential learners know about it. Where can you link to your course? If public, is social media an option?
Make sure your course includes keywords and text that someone would search for in Google and other search engines.
© 2025 GitHub, Inc.
Terms
Privacy
Status
Pricing
Expert Services
Blog

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[TheodorvonHaft]

Skip to main content
GitHub-Dokumentation
Erste Schritte/Schreiben auf GitHub/Einstieg in das Schreiben auf GitHub/Grundlegende Formatierungssyntax
Grundlegende Schreib- und Formatierungssyntax
Erstelle mit einer einfachen Syntax eine ausgereifte Formatierung für deine Texte und Codes auf GitHub.

Wer kann dieses Feature verwenden?
Markdown kann auf der Webbenutzeroberfläche von GitHub verwendet werden.

In diesem Artikel
Überschriften
Formatieren von Text
Zitieren von Text
Code zitieren
Unterstützte Farbmodelle
Verknüpfungen
Links zu Abschnitten
Relative Links
Benutzerdefinierte Anker
Zeilenumbrüche
Bilder
Listen
Aufgabenlisten
Personen und Teams erwähnen
Auf Issues und Pull Requests verweisen
Auf externe Ressourcen verweisen
Ressourcen hochladen
Emojis verwenden
Absätze
Fußnoten
Alerts
Inhalt mit Kommentaren ausblenden
Markdown-Formatierung ignorieren
Deaktivieren des Markdown-Renderings
Weitere Informationsquellen
Überschriften
Um eine Überschrift zu erstellen, kannst du bis zu sechs Rautensymbole (#) vor dem Text der Überschrift hinzufügen. Die Anzahl der verwendeten Rauten (#) bestimmt die Hierarchieebene und die Schriftgröße der Überschrift.

A first-level heading

A second-level heading

A third-level heading

Screenshot des gerenderten GitHub-Markdown mit Beispielen für die Überschriften h1, h2 und h3, die in Schriftgröße und visueller Gewichtung abnehmen, um die Hierarchieebene anzuzeigen

Wenn du mindestens zwei Überschriften verwendest, generiert GitHub automatisch ein Inhaltsverzeichnis, auf das du zugreifen kannst, indem du innerhalb des Dateiheaders auf klickst. Die einzelnen Überschriftentitel werden im Inhaltsverzeichnis aufgeführt, und du kannst auf einen Titel klicken, um zum gewünschten Abschnitt zu navigieren.

Screenshot einer Infodatei mit dem Dropdownmenü für das Inhaltsverzeichnis, das verfügbar gemacht wird. Das Symbol für das Inhaltsverzeichnis ist in dunklem Orange eingerahmt.

Formatieren von Text
Du kannst Text in Kommentarfeldern und Dateien vom Typ .md mittels Fettformatierung, Kursivformatierung, durchgestrichenem, tief- oder hochgestelltem Text hervorheben.

Style Syntax Tastenkombinationen Beispiel Output
Fett ** ** oder __ __ BEFEHL+B (Mac) oder STRG+B (Windows/Linux) This is bold text Dieser Text ist fett.
Kursiv * * oder _ _      BEFEHL+I (Mac) oder STRG+I (Windows/Linux) This text is italicized Dieser Text ist kursiv.
Durchgestrichen ~~ ~~ oder ~ ~ Keine This was mistaken text Dieser Text war falsch.
Fett und kursiv verschachtelt ** ** und _ _ Keine This text is extremely important Dieser Text ist sehr wichtig.
Alles fett und kursiv *** *** Keine All this text is important Dieser gesamte Text ist wichtig.
Tiefgestellt Keine This is a _subscript text Dies ist ein tiefgestellter Text.
Hochgestellt Keine This is a ^superscript text Dies ist ein hochgestellter Text.
Unterstrich Keine This is an underlined text Dies ist ein unterstrichener Text.
Zitieren von Text
Text kann mit dem folgenden Zeichen zitiert werden: >.

Text that is not a quote

Text that is a quote
Zitierter Text wird mit einer vertikalen Linie auf der linken Seite eingerückt und mit grauem Typ angezeigt.

Screenshot des gerenderten GitHub-Markdown mit dem Unterschied zwischen normalem und zitierten Text

Hinweis

In einer Unterhaltung kannst du Text in einem Kommentar automatisch zitieren, indem du den Text markierst und anschließend R drückst. Wenn du einen vollständigen Kommentar zitieren möchtest, kannst du auf und anschließend auf Antwort mit Zitat klicken. Weitere Informationen zu Tastenkombinationen findest du unter Tastenkombinationen.

Code zitieren
Du kannst Code oder einen Befehl innerhalb eines Satzes mit einfachen Backticks zitieren. Der Text innerhalb der Backticks wird nicht formatiert. Du kannst auch die Tastenkombination BEFEHL+E (Mac) oder STRG+E (Windows/Linux) verwenden, um die Backticks für einen Codeblock innerhalb einer Markdownzeile einzufügen.

Use git status to list all new or modified files that haven't yet been committed.
Screenshot des gerenderten GitHub-Markdown, der zeigt, dass Zeichen, die von Backticks umgeben sind, in einer Schriftart mit fester Breite angezeigt werden, was hellgrau hervorgehoben ist

Um Code oder einen Text in einem eigenen Absatz zu formatieren, verwende dreifache Backticks.

Some basic Git commands are:

git status
git add
git commit

Screenshot des gerenderten GitHub-Markdown mit einem einfachen Codeblock ohne Syntaxmarkierung

Weitere Informationen finden Sie unter Code-Blöcke erstellen und markieren.

Wenn du häufig Codeausschnitte und Tabellen bearbeitest, profitierst du möglicherweise von einer Schriftart mit fester Breite in allen Kommentarfeldern auf GitHub. Weitere Informationen finden Sie unter Informationen zum Schreiben und Formatieren bei GitHub.

Unterstützte Farbmodelle
In Issues, Pull Requests und Diskussionen kannst du mit Backticks Farben innerhalb eines Satzes aufrufen. Ein unterstütztes Farbmodell in Backticks zeigt eine Visualisierung der Farbe an.

The background color is #ffffff for light mode and #000000 for dark mode.
Screenshot des gerenderten GitHub-Markdown, der zeigt, wie HEX-Werte in Backticks kleine Farbkreise erstellen, in diesem Fall zuerst weiß und dann schwarz

Hier findest du die derzeit unterstützten Farbmodelle.

Color Syntax Beispiel Output
HEX #RRGGBB #0969DA Screenshot des gerenderten GitHub-Markdowns, der zeigt, wie der HEX-Wert #0969DA mit einem blauen Kreis angezeigt wird.
RGB rgb(R,G,B) rgb(9, 105, 218) Screenshot des gerenderten GitHub-Markdowns, der zeigt, wie der RGB-Wert 9, 105, 218 mit einem blauen Kreis angezeigt wird.
HSL hsl(H,S,L) hsl(212, 92%, 45%) Screenshot des gerenderten GitHub-Markdowns, der zeigt, wie der HSL-Wert 212, 92%, 45% mit einem blauen Kreis angezeigt wird.
Hinweis

Ein unterstütztes Farbmodell darf keine führenden oder nachgestellten Leerzeichen innerhalb der Backticks aufweisen.
Die Visualisierung der Farbe wird nur in Issues, Pull Requests und Diskussionen unterstützt.
Verknüpfungen
Du kannst einen Inlinelink erstellen, indem du den Text in eckige Klammern [ ] und die URL in runde Klammern ( ) einschließt. Du kannst auch die Tastenkombination BEFEHL+K verwenden, um einen Link zu erstellen. Wenn Text ausgewählt ist, kannst du eine URL aus der Zwischenablage einfügen, um automatisch einen Link aus der Auswahl zu erstellen.

Du kannst auch einen Markdownlink erstellen, indem du den Text markierst und die Tastenkombination BEFEHL+V verwendest. Wenn du den Text durch den Link ersetzen möchtest, verwende die Tastenkombination BEFEHL+UMSCHALT+V.

This site was built using GitHub Pages.

Screenshot des gerenderten GitHub-Markdowns, der zeigt, wie Text in Klammern, „GitHub Pages“, als blauer Link angezeigt wird.

Hinweis

GitHub erstellt automatisch Links, wenn du gültige URLs in einen Kommentar einfügst. Weitere Informationen finden Sie unter Automatisch verlinkte Verweise und URLs.

Links zu Abschnitten
Sie können direkt eine Verknüpfung mit jedem Abschnitt mit einer Überschrift vornehmen. Um den automatisch generierten Anker in einer gerenderten Datei anzuzeigen, zeigen Sie mit der Maus auf die Abschnittsüberschrift, um das -Symbol verfügbar zu machen, und klicken Sie auf das Symbol, um den Anker in Ihrem Browser anzuzeigen.

Screenshot einer Infodatei für ein Repository. Links neben einer Abschnittsüberschrift ist ein Linksymbol dunkelorange umrandet.

Wenn Sie den Anker für eine Überschrift in einer von Ihnen bearbeiteten Datei bestimmen müssen, können Sie sich an die folgenden Grundregeln halten:

Buchstaben werden in Kleinbuchstaben konvertiert.
Leerzeichen werden durch Bindestriche (-) ersetzt. Alle anderen Leerzeichen oder Interpunktionszeichen werden entfernt.
Führende und nachgestellte Leerzeichen werden entfernt.
Markupformatierung wird entfernt, sodass nur der Inhalt übrig bleibt (z. B. wird italics zu italics).
Wenn der automatisch generierte Anker für eine Überschrift mit einem früheren Anker im selben Dokument identisch ist, wird ein eindeutiger Bezeichner durch Anfügen eines Bindestrichs und einer automatisch erhöhten ganzen Zahl generiert.
Ausführlichere Informationen zu den Anforderungen von URI-Fragmenten finden Sie unter RFC 3986: Uniform Resource Identifier (URI): Generische Syntax, Abschnitt 3.5.

Der folgende Codeblock veranschaulicht die Grundregeln zum Generieren von Ankern aus Überschriften in gerenderten Inhalten.

Example headings

Sample Section

This'll be a Helpful Section About the Greek Letter Θ!

A heading containing characters not allowed in fragments, UTF-8 characters, two consecutive spaces between the first and second words, and formatting.

This heading is not unique in the file

TEXT 1

This heading is not unique in the file

TEXT 2

Links to the example headings above

Link to the sample section: Link Text.

Link to the helpful section: Link Text.

Link to the first non-unique section: Link Text.

Link to the second non-unique section: Link Text.
Hinweis

Wenn Sie eine Überschrift bearbeiten oder die Reihenfolge von Überschriften mit „identischen“ Ankern ändern, müssen Sie auch Links zu diesen Überschriften aktualisieren, da sich die Anker ändern.

Relative Links
Du kannst relative Links und Bildpfade in deinen gerenderten Dateien definieren, um Leser dabei zu unterstützen, in deinem Repository zu anderen Dateien zu navigieren.

Ein relativer Link ist ein Verknüpfung, die relativ zur aktuellen Datei ist. Wenn sich beispielsweise eine README-Datei im Root deines Repositorys und eine andere Datei in docs/CONTRIBUTING.md befindet, sieht der relative Link zu CONTRIBUTING.md in deiner README-Datei wie folgt aus:

Contribution guidelines for this project
GitHub wandelt deinen relativen Link oder Bildpfad automatisch anhand dessen um, in welchem Branch du dich gerade befindest, damit der Link oder der Pfad immer funktioniert. Der Pfad des Links ist relativ zur aktuellen Datei. Links, die mit / beginnen, sind relativ zum Repositorystamm. Du kannst alle relativen Linkoperanden verwenden, z. B. ./ und ../.

Ihr Linktext sollte sich in einer einzelnen Zeile befindet. Das folgende Beispiel funktioniert nicht.

Contribution
guidelines for this project
Relative Links sind für Benutzer, die dein Repository klonen, einfacher zu verwenden. Absolute Links funktionieren möglicherweise nicht in Klons deines Repositorys - wir empfehlen relative Links zu verwenden, um auf andere Dateien in deinem Repository zu verweisen.

Benutzerdefinierte Anker
Sie können standardmäßige HTML-Ankertags () verwenden, um Navigationsankerpunkte für eine beliebige Position im Dokument zu erstellen. Um mehrdeutige Verweise zu vermeiden, sollten Sie ein eindeutiges Benennungsschema für Ankertags verwenden, indem Sie z. B. eines Präfix zum Attributwert name hinzufügen.

Hinweis

Benutzerdefinierte Anker werden nicht in die Dokumentgliederung/das Inhaltsverzeichnis aufgenommen.

Sie können eine Verknüpfung mit einem benutzerdefinierten Anker unter Verwendung des Wert des Attributs name herstellen, das Sie dem Anker gegeben haben. Die Syntax ist genau gleich wie beim Verknüpfen mit einem Anker, der für eine Überschrift automatisch generiert wird.

Zum Beispiel:

Section Heading

Some body text of this section.

Some text I want to provide a direct link to, but which doesn't have its own heading.

(… more content…)

A link to that custom anchor
Tipp

Benutzerdefinierte Anker werden vom automatischen Benennungs- und Nummerierungsverhalten automatischer Überschriftenlinks nicht berücksichtigt.

Zeilenumbrüche
Wenn du Issues, Pull Requests oder Diskussionen in einem Repository schreibst, rendert GitHub automatisch einen Zeilenumbruch:

This example
Will span two lines
Wenn du jedoch in einer MD-Datei schreibst, würde das obige Beispiel in einer Zeile ohne Zeilenumbruch gerendert. Um einen Zeilenumbruch in einer MD-Datei zu erstellen, musst du eines der folgenden Elemente einschließen:

Schließe am Ende der ersten Zeile zwei Leerzeichen ein.

This example
Will span two lines
Schließe einen umgekehrten Schrägstrich am Ende der ersten Zeile ein.

This example
Will span two lines
Füge am Ende der ersten Zeile ein HTML-Tag für einen einzelnen Zeilenumbruch hinzu.

This example

Will span two lines
Wenn du eine leere Zeile zwischen zwei Zeilen lässt, werden sowohl MD-Dateien als auch Markdown in Issues, Pull Requests und Diskussionen die beiden Zeilen durch die leere Zeile getrennt gerendert:

This example

Will have a blank line separating both lines
Bilder
Du kannst ein Bild anzeigen, indem du ! hinzufügst und den Alternativtext mit [ ] umschließt. Alternativtext ist ein kurzer Text, der den Informationen im Bild entspricht. Umschließe dann den Link für das Bild mit Klammern ().

Screenshot eines Kommentars zu einem GitHub-Issue, das ein im Markdown hinzugefügtes Bild von Octocat zeigt, die lächelt und einen Tentakel hebt.

GitHub unterstützt das Einbetten von Bildern in Issues, Pull Requests, Diskussionen, Kommentare und Dateien vom Typ .md. Du kannst ein Bild aus deinem Repository anzeigen, einen Link zu einem Onlinebild hinzufügen oder ein Bild hochladen. Weitere Informationen findest du unter Hochladen von Ressourcen.

Hinweis

Wenn du ein Bild anzeigen möchtest, das sich in deinem Repository befindet, solltest du keine absoluten Links, sondern relative Links verwenden.

Hier findest du einige Beispiele für die Verwendung relativer Links zum Anzeigen eines Bilds.

Kontext Relativer Link
In einer Datei vom Typ .md im gleichen Branch /assets/images/electrocat.png
In einer Datei vom Typ .md in einem anderen Branch /../main/assets/images/electrocat.png
In Issues, Pull Requests und Kommentaren des Repositorys ../blob/main/assets/images/electrocat.png?raw=true
In einer Datei vom Typ .md in einem anderen Repository /../../../../github/docs/blob/main/assets/images/electrocat.png
In Issues, Pull Requests und Kommentaren eines anderen Repositorys ../../../github/docs/blob/main/assets/images/electrocat.png?raw=true
Hinweis

Die letzten beiden relativen Links in der obigen Tabelle funktionieren nur für Bilder in einem privaten Repository, wenn der Betrachter mindestens Lesezugriff auf das private Repository besitzt, das die Bilder enthält.

Weitere Informationen findest du unter Relative Links.

Das Bildelement
Das -HTML-Element wird unterstützt.

Listen
Du kannst eine ungeordnete Liste erstellen, indem du einer Textzeile oder mehreren Textzeilen -, * oder + voranstellst.

• George Washington

• John Adams

• Thomas Jefferson
  Screenshot des gerenderten GitHub-Markdowns mit einer Aufzählung der Namen der ersten drei amerikanischen Präsidenten.

Um deine Liste zu ordnen, stelle jeder Zeile eine Zahl voran.

1. James Madison
2. James Monroe
3. John Quincy Adams
   Screenshot des gerenderten GitHub-Markdowns mit einer nummerierten Liste der Namen des vierten, fünften und sechsten amerikanischen Präsidenten.

Verschachtelte Listen
Du kannst eine verschachtelte Liste erstellen, indem du ein Listenelement oder mehrere Listenelemente unter einem anderen Element einrückst.

Beim Web-Editor in GitHub oder bei einem Text-Editor wie Visual Studio Code, der eine Festbreitenschriftart verwendet, kannst du deine Liste visuell ausrichten. Gib vor dem einzurückenden Listenelement so viele Leerzeichen ein, bis das Listenzeichen (- oder *) direkt unter dem ersten Zeichen des darüber liegenden Elements liegt.

1. First list item
   • First nested list item
     • Second nested list item
       Hinweis

Im webbasierten Editor kannst du eine oder mehrere Textzeilen ein- oder ausrücken, indem du zuerst die gewünschten Zeilen markierst und dann TAB bzw. UMSCHALT+TAB drückst.

Screenshot von Markdown in Visual Studio Code mit Einzug geschachtelter nummerierter Zeilen und Aufzählungszeichen

Screenshot des gerenderten GitHub-Markdown mit einem nummerierten Element gefolgt von geschachtelten Aufzählungszeichen auf zwei verschiedenen Schachtelungsebenen

Um eine verschachtelte Liste im Kommentar-Editor auf GitHub zu erstellen, der keine nicht proportionale Schriftart verwendet, kannst du dir das Listenelement direkt über der verschachtelten Liste ansehen und die Anzahl der Zeichen zählen, die vor dem Inhalt dieses Elements stehen. Gib diese Anzahl an Leerzeichen dann vor dem untergeordneten Listenelement ein.

In diesem Beispiel kannst du ein untergeordnetes Listenelement unter dem Listenelement 100. First list item hinzufügen, indem du das untergeordnete Listenelement mindestens fünf Leerzeichen weit einrückst, da sich vor First list item fünf Zeichen (100. ) befinden.

100. First list item
     • First nested list item
       Screenshot des gerenderten GitHub-Markdown mit einem nummerierten Element, dem die Zahl 100 vorangestellt ist, gefolgt von einem Aufzählungselement, das eine Ebene eingerückt ist

Du kannst mit derselben Methode mehrere Ebenen an verschachtelten Listen erstellen. Ein Beispiel: Da das erste geschachtelte Listenelement vor dem geschachtelten Listeninhalt First nested list item sieben Zeichen (␣␣␣␣␣-␣) enthält, musst du das zweite geschachtelte Listenelement um mindestens zwei weitere Zeichen (mindestens neun Leerzeichen) einrücken.

100. First list item
     • First nested list item
       • Second nested list item
         Screenshot des gerenderten GitHub-Markdown mit einem nummerierten Element, dem die Nummer 100 gefolgt von Aufzählungszeichen auf zwei verschiedenen Schachtelungsebenen vorangestellt ist

Weitere Beispiele findest du in der Spezifikation zu GitHub Flavored Markdown.

Aufgabenlisten
Um eine Aufgabenliste zu erstellen, stellst du den Listenelementen einen Bindestrich und ein Leerzeichen gefolgt von [ ] voran. Um eine Aufgabe als erledigt zu markieren, verwende [x].

• child-count #739
• https://github.com/octo-org/octo-repo/issues/740
• Add delight to the experience when all tasks are complete 🎉
  Screenshot: Gerenderte Version des Markdowns. Die Verweise auf Issues werden als Issuetitel gerendert.

Wenn die Beschreibung eines Aufgabenlistenelements mit einer Klammer beginnt, muss die Klammer mit dem Escapezeichen \ versehen werden:

• (Optional) Open a followup issue

Weitere Informationen finden Sie unter Informationen zu Aufgabenlisten.

Personen und Teams erwähnen
Du kannst eine Person oder ein Team in GitHub erwähnen, indem du @ sowie den Benutzer- oder Teamnamen eingibst. Dadurch wird eine Benachrichtigung ausgelöst und die Aufmerksamkeit auf die Unterhaltung gelenkt. Wenn du einen Kommentar bearbeitest und dabei den Benutzer- oder Teamnamen erwähnst, wird die Person respektive das Team ebenfalls benachrichtigt. Weitere Informationen zu Benachrichtigungen findest du unter Informationen zu Benachrichtigungen.

Hinweis

Eine Person wird nur über eine Erwähnung benachrichtigt, wenn die Person Lesezugriff auf das Repository hat. Falls das Repository einer Organisation gehört, muss die Person außerdem der Organisation angehören.

@github/support What do you think about these updates?

Screenshot des gerenderten GitHub-Markdowns, der zeigt, wie die Erwähnung des Teams @github/support als anklickbarer Text in Fettformatierung dargestellt wird.

Wenn du ein übergeordnetes Team erwähnst, erhalten auch die Mitglieder untergeordneter Teams Benachrichtigungen, was die Kommunikation mit mehreren Personengruppen erleichtert. Weitere Informationen finden Sie unte