Skip to main content

Syntaxe d’écriture et de mise en forme de base

Créez une mise en forme sophistiquée pour votre prose et votre code sur GitHub avec une syntaxe simple.

Qui peut utiliser cette fonctionnalité ?

Markdown peut être utilisé dans l’interface web GitHub.

En-têtes

Pour créer un titre, ajoutez un à six # symboles avant le texte de votre titre. Le nombre d’utilisations # détermine le niveau hiérarchique et la taille de police du titre.

# A first-level heading
## A second-level heading
### A third-level heading

Capture d’écran du rendu GitHub Markdown montrant l’exemple d’en-têtes h1, h2 et h3, qui descendent en taille de type et poids visuel pour afficher le niveau de hiérarchie.

Lorsque vous utilisez deux titres ou plus, GitHub génère automatiquement une table des matières accessible en cliquant sur l’icône de menu « Contour » dans l’en-tête de fichier. Chaque titre de titre est répertorié dans la table des matières et vous pouvez cliquer sur un titre pour accéder à la section sélectionnée.

Capture d’écran d’un fichier README avec le menu déroulant de la table des matières exposée. L’icône de table des matières est décrite en orange foncé.

Mise en forme du texte

Vous pouvez indiquer l’accent mis en gras, italique, barré, indice ou texte exposant dans les champs de commentaire et .md les fichiers.

StyleSyntaxeRaccourci clavierExampleOutput
Bold
          `** **` ou `__ __`| 
          <kbd>Command</kbd>+<kbd>B</kbd> (Mac) ou <kbd>Ctrl</kbd>+<kbd>B</kbd> (Windows/Linux) | `**This is bold text**` | 
          **Il s’agit d’un texte en gras** |

| Italique | * * ou _ _    | Command+I (Mac) ou Ctrl+I (Windows/Linux) | _This text is italicized_ | Ce texte est italique | | Texte barré | ~~ ~~ ou ~ ~ | Aucun | ~~This was mistaken text~~ | Ce texte a été erroné | | En gras et en italique imbriqué | ** ** et _ _ | Aucun | **This text is _extremely_ important** | Ce texte est extrêmement important | | Tout gras et italique | *** *** | Aucun | ***All this text is important*** | Tout ce texte est important | | Indice | <sub> </sub> | Aucun | This is a <sub>subscript</sub> text | Il s’agit d’un texte d’indice | | Exposant | <sup> </sup> | Aucun | This is a <sup>superscript</sup> text | Il s’agit d’un texte exposant | | Souligné | <ins> </ins> | Aucun | This is an <ins>underlined</ins> text | Il s’agit d’un texte souligné |

Citation de texte

Vous pouvez citer du texte avec un >.

Text that is not a quote

> Text that is a quote

Le texte entre guillemets est mis en retrait avec une ligne verticale à gauche et affiché en gris.

Capture d’écran du rendu GitHub Markdown montrant la différence entre le texte normal et le texte entre guillemets.

Remarque

Lorsque vous affichez une conversation, vous pouvez citer automatiquement du texte dans un commentaire en mettant en surbrillance le texte, puis en tapant R. Vous pouvez citer un commentaire entier en cliquant sur , puis citation réponse. Pour plus d’informations sur les raccourcis clavier, consultez Raccourcis clavier.

Citation de code

Vous pouvez appeler du code ou une commande dans une phrase avec des backticks uniques. Le texte dans les backticks ne sera pas mis en forme. Vous pouvez également appuyer sur Command+E (Mac) ou Ctrl>Ctrl clavier +E (Windows/Linux) pour insérer les backticks d’un bloc de code dans une ligne de Markdown.

Use `git status` to list all new or modified files that haven't yet been committed.

Capture d’écran du rendu GitHub Markdown montrant que les caractères entourés de backticks sont affichés dans une police de largeur fixe, mise en surbrillance en gris clair.

Pour mettre en forme du code ou du texte dans son propre bloc distinct, utilisez des backticks triples.

Some basic Git commands are:
```
git status
git add
git commit
```

Capture d’écran du rendu GitHub Markdown montrant un bloc de code simple sans mise en surbrillance de syntaxe.

Pour plus d’informations, consultez « Création et mise en évidence de blocs de code ».

Si vous modifiez fréquemment des extraits de code et des tableaux, vous pourriez bénéficier de l'activation d'une police à largeur fixe dans tous les champs de commentaire sur GitHub. Pour plus d’informations, consultez « À propos de l’écriture et de la mise en forme sur GitHub ».

Modèles de couleurs pris en charge

Dans les problèmes, les pull requests et les discussions, vous pouvez mentionner des couleurs dans une phrase à l’aide de backticks. Un modèle de couleur pris en charge dans les backticks affiche une visualisation de la couleur.

The background color is `#ffffff` for light mode and `#000000` for dark mode.

Capture d’écran du rendu GitHub Markdown montrant comment les valeurs HEX dans les backticks créent de petits cercles de couleur, ici blanc, puis noir.

Voici les modèles de couleurs actuellement pris en charge.

ColorSyntaxeExampleOutput
HEX`#RRGGBB``#0969DA`Capture d’écran du rendu GitHub Markdown montrant comment la valeur HEX #0969DA apparaît avec un cercle bleu.
RVB`rgb(R,G,B)``rgb(9, 105, 218)`Capture d’écran du rendu GitHub Markdown montrant comment la valeur RVB 9, 105, 218 apparaît avec un cercle bleu.
HSL`hsl(H,S,L)``hsl(212, 92%, 45%)`Capture d’écran du rendu GitHub Markdown montrant comment la valeur HSL 212, 92%, 45% apparaît avec un cercle bleu.

Remarque

  • Un modèle de couleur pris en charge ne peut pas avoir d’espaces de début ou de fin dans les backticks.
  • La visualisation de la couleur est uniquement prise en charge dans les problèmes, les pull requests et les discussions.

Vous pouvez créer un lien inline en encapsulant le texte du lien entre crochets [ ], puis en encapsulant l’URL entre parenthèses ( ). Vous pouvez également utiliser la commande de+ raccourci clavierK pour créer un lien. Lorsque vous avez sélectionné du texte, vous pouvez coller une URL à partir de votre Presse-papiers pour créer automatiquement un lien à partir de la sélection.

Vous pouvez également créer un lien hypertexte Markdown en mettant en surbrillance le texte et en utilisant la commande de+ raccourci clavierV. Si vous souhaitez remplacer le texte par le lien, utilisez le raccourci clavier Command+Maj+V.

This site was built using [GitHub Pages](https://pages.github.com/).

Capture d’écran du rendu GitHub Markdown montrant comment le texte entre crochets , « GitHub Pages », apparaît sous forme de lien hypertexte bleu.

Remarque

GitHub crée automatiquement des liens lorsque des URL valides sont écrites dans un commentaire. Pour plus d’informations, consultez « Références et URL automatiquement liées ».

Vous pouvez créer un lien direct vers n’importe quelle section comportant un titre. Pour afficher l’ancre générée automatiquement dans un fichier rendu, survolez le titre de la section pour faire apparaître l’icône et cliquez sur l’icône pour afficher l’ancre dans votre navigateur.

Capture d’écran d’un fichier README pour un référentiel. À gauche d'un titre de section, une icône de lien est indiquée en orange foncé.

Si vous devez déterminer l’ancre d’un titre dans un fichier que vous modifiez, vous pouvez utiliser les règles de base suivantes :

  • Les lettres sont converties en minuscules.
  • Les espaces sont remplacés par des traits d’union (-). Tous les autres espaces blancs ou caractères de ponctuation sont supprimés.
  • Les espaces blancs de début et de fin sont supprimés.
  • La mise en forme du balisage est supprimée, en laissant uniquement le contenu (par exemple, _italics_ devient italics).
  • Si l’ancre générée automatiquement pour un titre est identique à une ancre antérieure dans le même document, un identificateur unique est généré en ajoutant un trait d’union et un entier incrémentant automatiquement.

Pour plus d’informations sur les exigences des fragments d’URI, consultez RFC 3986 : URI (Uniform Resource Identifier) : Syntaxe générique, section 3.5.

Le bloc de code ci-dessous illustre les règles de base utilisées pour générer des ancres à partir de titres dans le contenu rendu.

# 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](#sample-section).

Link to the helpful section: [Link Text](#thisll-be-a-helpful-section-about-the-greek-letter-Θ).

Link to the first non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file).

Link to the second non-unique section: [Link Text](#this-heading-is-not-unique-in-the-file-1).

Remarque

Si vous modifiez un titre ou si vous modifiez l’ordre des en-têtes avec des ancres « identiques », vous devez également mettre à jour les liens vers ces titres, car les ancres changeront.

Vous pouvez définir des liens et des chemins d’image relatifs dans vos fichiers affichés pour aider les lecteurs à accéder à d’autres fichiers de votre dépôt.

Un lien relatif est relatif par rapport au fichier actuel. Par exemple, si vous avez un fichier README à la racine de votre dépôt et que vous avez un autre fichier dans docs/CONTRIBUTING.md, le lien relatif vers CONTRIBUTING.md dans votre fichier README peut ressembler à ceci :

[Contribution guidelines for this project](docs/CONTRIBUTING.md)

GitHub transformera automatiquement votre lien relatif ou le chemin d'accès à l'image en fonction de la branche sur laquelle vous vous trouvez actuellement, de sorte que le lien ou le chemin d'accès fonctionne toujours. Le chemin du lien sera relatif au fichier actif. Les liens commençant par / seront relatifs à la racine du dépôt. Vous pouvez utiliser tous les opérandes de lien relatif, comme ./ et ../.

Votre texte de lien doit se trouver sur une seule ligne. L’exemple ci-dessous ne fonctionnera pas.

[Contribution
guidelines for this project](docs/CONTRIBUTING.md)

Les liens relatifs sont plus pratiques pour les utilisateurs qui clonent votre dépôt. Les liens absolus peuvent ne pas fonctionner dans les clones de votre dépôt. Nous vous recommandons d’utiliser des liens relatifs pour référencer d’autres fichiers au sein de votre dépôt.

Ancres personnalisées

Vous pouvez utiliser des balises d’ancrage HTML standard (<a name="unique-anchor-name"></a>) pour créer des points d’ancrage de navigation pour n’importe quel emplacement du document. Pour éviter les références ambiguës, utilisez un schéma d’affectation de noms unique pour les balises d’ancrage, comme l’ajout d’un préfixe à la valeur d’attribut name .

Remarque

Les ancres personnalisées ne seront pas incluses dans le plan du document/Table des matières.

Vous pouvez lier à une ancre personnalisée à l’aide de la valeur de l’attribut name que vous avez donné à l’ancre. La syntaxe est exactement la même que lorsque vous liez à une ancre générée automatiquement pour un titre.

Par exemple:

# Section Heading

Some body text of this section.

<a name="my-custom-anchor-point"></a>
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](#my-custom-anchor-point)

Conseil

Les ancres personnalisées ne sont pas prises en compte par le comportement de nommage et de numérotation automatiques des liens de titre automatique.

Sauts de ligne

Si vous écrivez des problèmes, des demandes de tirage ou des discussions dans un référentiel, GitHub affiche automatiquement un saut de ligne :

This example
Will span two lines

Toutefois, si vous écrivez dans un fichier .md, l’exemple ci-dessus s’affiche sur une ligne sans saut de ligne. Pour créer un saut de ligne dans un fichier .md, vous devez inclure l’une des opérations suivantes :

  • Incluez deux espaces à la fin de la première ligne.

    This example  
    Will span two lines
    
  • Incluez une barre oblique inverse à la fin de la première ligne.

    This example\
    Will span two lines
    
  • Incluez une balise d’arrêt de ligne UNIQUE HTML à la fin de la première ligne.

    This example<br/>
    Will span two lines
    

Si vous laissez une ligne vide entre deux lignes, les fichiers .md et Markdown dans les problèmes, les pull requests et les discussions affichent les deux lignes séparées par la ligne vide :

This example

Will have a blank line separating both lines

Images

Vous pouvez afficher une image en ajoutant ! et encapsuler le texte de remplacement dans [ ]. Le texte de remplacement est un texte court équivalent aux informations de l’image. Ensuite, encapsulez le lien de l’image entre parenthèses ().

![Screenshot of a comment on a GitHub issue showing an image, added in the Markdown, of an Octocat smiling and raising a tentacle.](https://myoctocat.com/assets/images/base-octocat.svg)

Capture d’écran d’un commentaire sur un problème de GitHub montrant une image, ajoutée dans le Markdown, d’un octocat souriant et de lever un tentacle.

GitHub prend en charge l’incorporation d’images dans vos problèmes, les demandes de tirage , discussions, commentaires et .md fichiers. Vous pouvez afficher une image à partir de votre référentiel, ajouter un lien à une image en ligne ou charger une image. Pour plus d’informations, consultez Charger des ressources.

Remarque

Lorsque vous souhaitez afficher une image qui se trouve dans votre référentiel, utilisez des liens relatifs plutôt que des liens absolus.

Voici quelques exemples d’utilisation de liens relatifs pour afficher une image.

ContexteLien relatif
Dans un .md fichier sur la même branche/assets/images/electrocat.png
Dans un fichier sur une .md autre branche/../main/assets/images/electrocat.png
Dans les issues, les pull requests et les commentaires du dépôt../blob/main/assets/images/electrocat.png?raw=true
Dans un fichier d’un .md autre référentiel/../../../../github/docs/blob/main/assets/images/electrocat.png
Dans les issues, les pull requests et les commentaires d’un autre référentiel../../../github/docs/blob/main/assets/images/electrocat.png?raw=true

Remarque

Les deux derniers liens relatifs dans le tableau ci-dessus fonctionnent pour les images d’un référentiel privé uniquement si la visionneuse a au moins un accès en lecture au référentiel privé qui contient ces images.

Pour plus d’informations, consultez Liens relatifs.

Élément Picture

L’élément <picture> HTML est pris en charge.

Lists

Vous pouvez créer une liste non triée en précédant une ou plusieurs lignes de texte avec -, *ou +.

- George Washington
* John Adams
+ Thomas Jefferson

Capture d’écran du rendu GitHub Markdown montrant une liste à puces des noms des trois premiers présidents américains.

Pour commander votre liste, faites précéder chaque ligne d’un nombre.

1. James Madison
2. James Monroe
3. John Quincy Adams

Capture d’écran du rendu GitHub Markdown montrant une liste numérotée des noms des quatrième, cinquième et sixième présidents américains.

Listes imbriquées

Vous pouvez créer une liste imbriquée en mettant en retrait un ou plusieurs éléments de liste sous un autre élément.

Pour créer une liste imbriquée à l’aide de l’éditeur web sur GitHub ou un éditeur de texte qui utilise une police monospaced, comme Visual Studio Code, vous pouvez aligner visuellement votre liste. Tapez des caractères d’espace devant votre élément de liste imbriqué jusqu’à ce que le caractère de marqueur de liste (- ou *) se trouve directement sous le premier caractère du texte de l’élément au-dessus de celui-ci.

1. First list item
   - First nested list item
     - Second nested list item

Remarque

Dans l’éditeur web, vous pouvez mettre en retrait ou dédenter une ou plusieurs lignes de texte en mettant d’abord en surbrillance les lignes souhaitées, puis en utilisant Tab ou Maj+Tab respectivement.

Capture d’écran de Markdown dans Visual Studio Code montrant la mise en retrait des lignes et puces numérotées imbriquées.

Capture d’écran du rendu GitHub Markdown montrant un élément numéroté suivi de puces imbriquées à deux niveaux différents d’imbrication.

Pour créer une liste imbriquée dans l’éditeur de commentaires sur GitHub, qui n’utilise pas de police monospaced, vous pouvez examiner l’élément de liste immédiatement au-dessus de la liste imbriquée et compter le nombre de caractères qui apparaissent avant le contenu de l’élément. Tapez ensuite ce nombre d'espaces devant l’élément de liste imbriqué.

Dans cet exemple, vous pouvez ajouter un élément de liste imbriqué sous l’élément 100. First list item de liste en mettant en retrait l’élément de liste imbriqué un minimum de cinq espaces, car il y a cinq caractères (100. ) avant First list item.

100. First list item
     - First nested list item

Capture d’écran du rendu GitHub Markdown montrant un élément numéroté précédé par le nombre 100 suivi d’un élément à puces imbriqué à un niveau.

Vous pouvez créer plusieurs niveaux de listes imbriquées à l’aide de la même méthode. Par exemple, étant donné que le premier élément de liste imbriqué a sept caractères (␣␣␣␣␣-␣) avant le contenu First nested list itemde la liste imbriquée, vous devez mettre en retrait le deuxième élément de liste imbriqué d’au moins deux caractères supplémentaires (neuf espaces minimum).

100. First list item
     - First nested list item
       - Second nested list item

Capture d’écran du rendu GitHub Markdown montrant un élément numéroté précédé par le nombre 100 suivi de puces à deux niveaux différents d’imbrication.

Pour plus d’exemples, consultez les GitHub Spécifications Markdown aromatisées.

Listes de tâches

Pour créer une liste de tâches, faites précéder les éléments de la liste d’un trait d’union et d’un espace, puis de [ ]. Pour marquer une tâche comme terminée, utilisez [x].

- [x] #739
- [ ] https://github.com/octo-org/octo-repo/issues/740
- [ ] Add delight to the experience when all tasks are complete :tada:

Capture d’écran montrant la version affichée du markdown. Les références aux problèmes sont affichées sous forme de titres de problème.

Si une description d’élément de liste de tâches commence par une parenthèse, vous devez l’échapper avec \:

- [ ] \(Optional) Open a followup issue

Pour plus d’informations, consultez « À propos des listes de tâches ».

Mention de personnes et d’équipes

Vous pouvez mentionner une personne ou une équipe sur GitHub en tapant @ plus son nom d’utilisateur ou son nom d’équipe. Cela déclenchera une notification et attirera l’attention sur la conversation. Les personnes recevront également une notification si vous modifiez un commentaire pour mentionner leur nom d’utilisateur ou leur nom d’équipe. Pour plus d’informations sur les notifications, consultez À propos des notifications.

Remarque

Une personne ne sera avertie d’une mention que si la personne a accès en lecture au référentiel et, si le référentiel appartient à une organisation, la personne est membre de l’organisation.

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

Capture d’écran du rendu GitHub Markdown montrant comment l’équipe mentionne « @github/support » s’affiche en gras, texte cliquable.

Lorsque vous mentionnez une équipe parente, les membres de ses équipes enfants reçoivent également des notifications, ce qui simplifie la communication avec plusieurs groupes de personnes. Pour plus d’informations, consultez « À propos des équipes d'organisation ».

La saisie d’un @ symbole affiche une liste de personnes ou d’équipes sur un projet. La liste se filtre au fur et à mesure que vous tapez, donc une fois que vous avez trouvé le nom de la personne ou de l'équipe que vous recherchez, vous pouvez utiliser les touches fléchées pour le sélectionner et appuyer sur la touche Tabulation ou Entrée pour valider le nom. Pour les équipes, entrez et @organization/team-name tous les membres de cette équipe seront abonnés à la conversation.

Les résultats de saisie semi-automatique sont limités aux collaborateurs du référentiel et à tous les autres participants sur le thread.

Référence des problèmes et des pull requests

Vous pouvez afficher une liste de problèmes suggérés et de demandes de tirage dans le référentiel en tapant #. Tapez le numéro ou le titre du problème ou de la pull request pour filtrer la liste, puis appuyez sur la touche Tab ou Entrée pour valider le résultat mis en surbrillance.

Pour plus d’informations, consultez « Références et URL automatiquement liées ».

Référencement des ressources externes

Si des références personnalisées de lien automatique sont configurées pour un référentiel, les références à des ressources externes, comme un problème de JIRA ou un ticket Zendesk, sont converties en liens raccourcis. Pour savoir quels liens automatiques sont disponibles dans votre référentiel, contactez une personne disposant d’autorisations d’administration sur le référentiel. Pour plus d’informations, consultez « Configuration de liens automatiques pour référencer des ressources externes ».

Chargement de ressources

Vous pouvez charger des ressources telles que des images en faisant glisser-déplacer, en sélectionnant à partir d’un navigateur de fichiers ou en collant. Vous pouvez charger des ressources dans des problèmes, des demandes de tirage(s), des commentaires et .md des fichiers dans votre référentiel.

Utilisation d’emojis

Vous pouvez ajouter des emojis à votre écriture en tapant :EMOJICODE:, un signe deux-points suivi du nom de l’emoji.

@octocat :+1: This PR looks great - it's ready to merge! :shipit:

Capture d’écran du rendu GitHub Markdown montrant comment les codes emoji pour +1 et shipit s’affichent visuellement en tant qu’emoji.

Saisie : affiche une liste d’emojis suggérés. La liste filtre à mesure que vous tapez. Par conséquent, une fois que vous trouvez l’emoji que vous recherchez, appuyez sur Tab ou Entrée pour terminer le résultat mis en surbrillance.

Pour obtenir la liste complète des emojis et codes disponibles, consultez la feuille Emoji-Cheat-Sheet.

Paragraphs

Vous pouvez créer un paragraphe en laissant une ligne vide entre les lignes de texte.

Notes de bas de page

Vous pouvez ajouter des notes de bas de page à votre contenu à l’aide de cette syntaxe de crochet :

Here is a simple footnote[^1].

A footnote can also have multiple lines[^2].

[^1]: My reference.
[^2]: To add line breaks within a footnote, add 2 spaces to the end of a line.  
This is a second line.

La note de bas de page s’affiche comme suit :

Capture d'écran du Markdown rendu montrant des numéros en exposant utilisés pour indiquer les notes de bas de page, ainsi que des sauts de ligne facultatifs dans une note.

Remarque

La position d’une note de bas de page dans votre Markdown n’influence pas l’endroit où la note de bas de page sera affichée. Vous pouvez écrire une note de bas de page juste après votre référence à la note de bas de page, et la note de bas de page s’affiche toujours en bas de Markdown. Les notes de bas de page ne sont pas prises en charge dans les wikis.

Alerts

          **Les alertes**, parfois **appelées légendes** ou **avertissements**, sont une extension Markdown basée sur la syntaxe blockquote que vous pouvez utiliser pour mettre en évidence les informations critiques. Sur GitHub, ils sont affichés avec des couleurs et des icônes distinctives pour indiquer l’importance du contenu.

Utilisez des alertes uniquement lorsqu’elles sont cruciales pour la réussite de l’utilisateur et qu’elles sont limitées à un ou deux par article pour empêcher la surcharge du lecteur. En outre, vous devez éviter de placer des alertes consécutivement. Les alertes ne peuvent pas être imbriquées dans d’autres éléments.

Pour ajouter une alerte, utilisez une ligne de bloc spéciale spécifiant le type d’alerte, suivie des informations d’alerte dans un blocquote standard. Cinq types d’alertes sont disponibles :

> [!NOTE]
> Useful information that users should know, even when skimming content.

> [!TIP]
> Helpful advice for doing things better or more easily.

> [!IMPORTANT]
> Key information users need to know to achieve their goal.

> [!WARNING]
> Urgent info that needs immediate user attention to avoid problems.

> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.

Voici les alertes rendues :

Capture d’écran des alertes Markdown affichées montrant le rendu de la Note, le Conseil, l'Important, l'Avertissement, et l'Attention avec du texte et des icônes de couleurs différentes.

Masquage du contenu avec des commentaires

Vous pouvez indiquer GitHub pour masquer le contenu du rendu Markdown en plaçant le contenu dans un commentaire HTML.

<!-- This content will not appear in the rendered Markdown -->

Ignorer la mise en forme Markdown

Vous pouvez indiquer à GitHub d’ignorer (ou d’échapper) la mise en forme Markdown à l’aide \ du caractère Markdown.

Let's rename \*our-new-project\* to \*our-old-project\*.

Capture d’écran du rendu GitHub Markdown montrant comment les barres obliques inverses empêchent la conversion d’astérisques en italiques.

Pour plus d’informations sur les barres obliques inverses, consultez la syntaxe Markdown de Daring Fireball.

Remarque

La mise en forme Markdown ne sera pas ignorée dans le titre d’un ticket ou d’une pull request.

Désactivation de l’affichage de Markdown

Lors de l’affichage d’un fichier Markdown, vous pouvez cliquer sur Code en haut du fichier pour désactiver le rendu Markdown et afficher la source du fichier à la place.

Capture d’écran d’un fichier Markdown dans un dépôt GitHub montrant les options d’interaction avec le fichier. Un bouton étiqueté « Code » est indiqué en orange foncé.

La désactivation du rendu Markdown vous permet d’utiliser des fonctionnalités d’affichage source, telles que la liaison de lignes, ce qui n’est pas possible lors de l’affichage des fichiers Markdown rendus.

Lectures complémentaires