GitLab Markdown

GitLab Markdown

该 Markdown 指南仅对 GitLab 的内部 Markdown 渲染系统的条目和文件有效 . 它是无效的GitLab 文档，网站或 ，因为它们都使用Kramdown作为他们的降价引擎. 文档网站使用扩展的 Kramdown 宝石 . 有关完整的 Kramdown 参考，请查阅《 GitLab Kramdown 指南》 .

注意：我们建议您查看此文档.

GitLab 使用” GitLab 风味降价”（GFM）. 它以几种方式扩展了CommonMark 规范 （基于标准 Markdown），以添加其他有用的功能. 它的灵感来自 .

您可以在以下区域使用 GFM：

  • Comments
  • Issues
  • 合并要求
  • Milestones
  • 代码段（代码段必须以扩展名命名）
  • 维基页面
  • 仓库中的 Markdown 文档
  • Epics

您还可以在 GitLab 中使用其他 RTF 文件. 您可能必须安装依赖项才能这样做. 请参阅gitlab-markup gem 项目以获取更多信息.

从 11.1 开始，GitLab 使用对Markit处理 GitLab 系统中的所有新问题，合并请求，注释和其他 Markdown 内容. 从 11.3 开始，存储库中的 Wiki 页面和 Markdown 文件（ *.md ）也将通过 CommonMark 处理. 从 11.8 开始， 已被删除，所有问题和注释，包括 11.1 之前的问题和注释，现在都可以使用CommonMark Ruby Library 处理 .

该文档网站的已于 2018 年 10 月从 Redcarpet 迁移到 Kramdown .

您的存储库中可能存在较旧的问题，合并请求或 Markdown 文档，这些文档是使用 GitLab 的 RedCarpet 版本的 Markdown 的细微差别编写的. 由于 CommonMark 使用了稍微严格的语法，因此自我们过渡到 CommonMark 以来，这些文档现在看起来可能会有所不同.

通常很容易修复. 例如，带嵌套列表的编号列表可能会错误显示：

只需在每个嵌套项目中添加一个空格即可使-与顶部列表项的第一个字符对齐（本例中为C ）：

  1. 1. Chocolate
  2.  - dark
  3.  - milk
  1. Chocolate
    • dark
    • milk

注意：我们将在本文档中标记 Redcarpet 和 CommonMark Markdown 之间的任何重大差异.

如果您有大量的 Markdown 文件，确定它们是否正确显示可能很繁琐. 您可以使用工具（不是官方支持的产品）来生成文件列表以及 RedCarpet 和 CommonMark 呈现文件的方式之间的差异. 它可以指示是否需要更改任何内容-通常不需要更改.

GFM extends standard Markdown

GitLab 充分利用了标准（CommonMark）格式，但还包括对 GitLab 用户有用的附加功能.

它利用了的新功能 ，这些是标准 Markdown 所没有的：

它还具有扩展的 Markdown 功能 ，而无需更改标准 Markdown 的使用方式：

New GFM Markdown extensions

Colors

如果未正确呈现，请 .

可以使用颜色指示器呈现以 HEX，RGB 或 HSL 格式书写的颜色.

支持的格式（不支持命名的颜色）：

  • HEX: #RGB[A] or #RRGGBB[AA]
  • RGB: RGB[A](R, G, B[, A])
  • HSL: HSL[A](H, S, L[, A])

反引号内的颜色后面将带有颜色”碎片”：

  1. - `#F00`
  2. - `#F00A`
  3. - `#FF0000`
  4. - `#FF0000AA`
  5. - `RGB(0,255,0)`
  6. - `RGB(0%,100%,0%)`
  7. - `RGBA(0,255,0,0.3)`
  8. - `HSL(540,70%,50%)`
  9. - `HSLA(540,70%,50%,0.3)`
  • #F00
  • #F00A
  • #FF0000
  • #FF0000AA
  • RGB(0,255,0)
  • RGB(0%,100%,0%)
  • RGBA(0,255,0,0.3)
  • HSL(540,70%,50%)
  • HSLA(540,70%,50%,0.3)

Diagrams and flowcharts

可以使用或PlantUML从 GitLab 中的文本生成图表和流程图.

Mermaid

在 GitLab 10.3 中引入 .

访问以获取更多详细信息. 如果您不熟悉使用 Mermaid，或者需要帮助来确定 Mermaid 代码中的问题，则Mermaid Live Editor是一个有用的工具，可用于在 Mermaid 图中创建和解决问题.

为了生成图表或流程图，您应该在mermaid块内编写文本：

  1. ```mermaid graph TD;
  2.   A-->B;
  3.   A-->C;
  4.   B-->D;
  5.   C-->D;
  2. 图 TD; A-> B; A-> C; B-> D; C-> D;
  4. 子图也可以包括：

```mermaid graph TB

SubGraph1 —> SubGraph1Flow subgraph “SubGraph 1 Flow” SubGraph1Flow(SubNode 1) SubGraph1Flow — Choice1 —> DoChoice1 SubGraph1Flow — Choice2 —> DoChoice2 end

subgraph “Main Graph” Node1[Node 1] —> Node2[Node 2] Node2 —> SubGraph1[Jump to SubGraph1] SubGraph1 —> FinalThing[Final Thing] end

  1. ```
  3. 图 TB SubGraph1-> SubGraph1Flow 子图" SubGraph 1 Flow" SubGraph1Flow（SubNode 1）SubGraph1Flow-Choice1-> DoChoice1 SubGraph1Flow-Choice2-> DoChoice2 结束子图" Main Graph" Node1 [Node 1]-> Node2 [ Node 2] Node2-> SubGraph1 [Jump to SubGraph1] SubGraph1-> FinalThing [Final Thing]结束
  5. #### PlantUML[](#plantuml "Permalink")
  7. 为了使 PlantUML 在 GitLab 中可用，GitLab 管理员需要首先启用它. 在[PlantUML＆GitLab 中]($administration-integration-plantuml.html)了解更多[信息]($administration-integration-plantuml.html) .
  9. ### Emoji[](#emoji "Permalink")
  11. > 如果未正确呈现，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#emoji) .

Sometimes you want to :monkey: around a bit and add some :star2: to your :speech_balloon:. Well we have a gift for you:

:zap: You can use emoji anywhere GFM is supported. :v:

You can use it to point out a :bug: or warn about :speak_no_evil: patches. And if someone improves your really :snail: code, send them some :birthday:. People will :heart: you for that.

If you’re new to this, don’t be :fearful:. You can easily join the emoji :family:. All you need to do is to look up one of the supported codes.

Consult the for a list of all supported emoji codes. :thumbsup: 

  2. 有时候你想 ![](/projects/gitlab-doc-zh/docs/img/a5023ba03c96276e989dc4dbff1ca8dd.png) 大约添加一些 ![](/projects/gitlab-doc-zh/docs/img/bb7ff3b17ad66e05a64ee12def63524b.png) 给你 ![](/projects/gitlab-doc-zh/docs/img/49d46d08d1ca6c3cd3d0b0ef98472512.png) . 好吧，我们有礼物送给您：
  4. ![](/projects/gitlab-doc-zh/docs/img/13b2b9b44dbf46de0243edc068ecab42.png)您可以在支持 GFM 的任何地方使用表情符号. ![](/projects/gitlab-doc-zh/docs/img/cff0e046ac8eca2d9fde8f13a3365d66.png)
  6. 您可以使用它指出一个 ![](/projects/gitlab-doc-zh/docs/img/7710cb575c3aefd0769c3f6aadb6e879.png) 或警告 ![](/projects/gitlab-doc-zh/docs/img/773702223af81c9872bccd88d63ad3a5.png) 补丁. 如果有人真的改善了你 ![](/projects/gitlab-doc-zh/docs/img/17e23e08ff33b405e039adae1f73cb83.png) 代码，给他们发送一些 ![](/projects/gitlab-doc-zh/docs/img/fd7124974fcca5463d2ce7385bfb700e.png) . 人们会 ![](/projects/gitlab-doc-zh/docs/img/bab86c57be5bd24c1329a7de56df456a.png) 为此.
  8. 如果您是新手，请不要 ![](/projects/gitlab-doc-zh/docs/img/e41f9ac1eea140d12bc83ea9312e71d0.png) . 您可以轻松加入表情符号 ![](/projects/gitlab-doc-zh/docs/img/d5171d012a8ff616032035f890d8dbd5.png) . 您需要做的只是查找受支持的代码之一.
  10. 有关所有受支持的表情符号代码的列表，请查阅[表情符号备忘单](https://www.webfx.com/tools/emoji-cheat-sheet/) . ![](/projects/gitlab-doc-zh/docs/img/d0b9fcc8669d772a04d7d72ccb5a82cc.png)
  12. > **注意：**以上表情符号示例在本文档中使用了硬编码图像. 在 GitLab 中呈现时，表情符号可能会出现不同，具体取决于所使用的操作系统和浏览器.
  14. 大多数 emoji 表情在 macOS，Windows，iOS，Android 上均受本机支持，并且将退回到不支持图像的基于图像的表情上.
  16. **注意：**在 Linux 上，您可以下载[Noto Color Emoji](https://www.google.com/get/noto/help/emoji/)以获得完整的本机表情符号支持. Ubuntu 18.04（与许多现代 Linux 发行版一样）默认情况下已安装此字体.
  18. ### Front matter[](#front-matter "Permalink")
  20. 在 GitLab 11.6 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23331) .
  22. 首要事项是 Markdown 文档开头，内容之前的元数据. 静态站点生成器（例如[Jekyll](https://jekyllrb.com/docs/front-matter/) ， [Hugo](https://s0gohugo0io.icopy.site/content-management/front-matter/)和许多其他应用程序）可以使用此数据.
  24. 当您查看由 GitLab 渲染的 Markdown 文件时，任何前端问题都会按原样显示在文档顶部的框中，位于渲染的 HTML 内容之前. 要查看示例，可以在[GitLab 文档文件](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/README.md)的源版本和渲染版本之间切换.
  26. 在 GitLab 中，仅在 Markdown 文件和 Wiki 页面中使用前题，而不在支持 Markdown 格式的其他地方使用. 它必须在文档的最顶部，并且必须在定界符之间，如下所述.
  28. 支持以下定界符：
  30. *   YAML（ `---` ）：
  1. ---
  2. title: About Front Matter
  3. example:
  4. language: yaml
  5. --- 
  6. ```

  • TOML（ +++ ）：

    1. +++
    2. title = "About Front Matter"
    3. [example]
    4. language = "toml"
    5. +++

  • JSON（ ;;; ）：

    1. ;;;  {  "title":  "About Front Matter"  "example":  {  "language":  "json"  }  }  ;;;

通过向任何现有定界符添加说明符来支持其他语言. 例如：

  1. ---php
  2. $title = "About Front Matter";
  3. $example = array(
  4.   'language' => "php",
  5. );
  6. ---

Inline diff

如果未正确呈现，请 .

使用内联 diff 标签，您可以显示{+ additions +}或[- deletions -] .

包装标签可以是大括号或方括号：

  1. - {+ addition 1 +}
  2. - [+ addition 2 +]
  3. - {- deletion 3 -}
  4. - [- deletion 4 -]
  • {+加法 1 +}
  • [+加法 2 +]
  • {-删除 3-}

但是，包装标签不能混合使用：

  1. - {+ addition +]
  2. - [+ addition +}
  3. - {- deletion -]
  4. - [- deletion -}

如果您的差异包含code字体的单词，请确保使用反斜杠\来转义每个反引号``` ，否则差异突出显示将无法正确呈现：

  1. - {+ Just regular text +}
  2. - {+ Text with `backticks` inside +}
  3. - {+ Text with escaped \`backticks\` inside +}
  • {+普通文字+}
  • {+带有backticks文字+}
  • {+内含转义的`反引号’的文字+}

Math

可以使用渲染用 LaTeX 语法编写的数学运算.

在美元符号$之间写的数学将与文本内嵌. 用声明为math的语言在代码块中编写的math将在单独的行上呈现：

  1. This math is inline $`a^2+b^2=c^2`$.
  3. This is on a separate line
  5. ```math a^2+b^2=c^2
  2. 此数学`a^2+b^2=c^2`为内联$ `a^2+b^2=c^2` $.
  4. 这是在单独的行上

a^2+b^2=c^2

  2. *请注意，KaTeX 仅支持 LaTeX 的[子集](https://katex.org/docs/supported.html) .*
  4. **注意：**这也适用于 Asciidoctor `:stem: latexmath` . 有关详细信息，请参见[Asciidoctor 用户手册](https://asciidoctor.org/docs/user-manual/#activating-stem-support) .
  6. ### Special GitLab references[](#special-gitlab-references "Permalink")
  8. GFM 可以识别与 GitLab 相关的特殊参考. 例如，您可以轻松地引用项目中的问题，提交，团队成员甚至整个团队. GFM 会将引用转换为链接，以便您可以轻松地在它们之间导航.
  10. 此外，GFM 可以识别某些跨项目引用，并且还具有一个速记版本，可以引用同一名称空间中的其他项目.
  12. GFM 将识别以下内容：
  14. | references | input | 跨项目参考 | shortcut within same namespace |
  15. | --- | --- | --- | --- |
  16. | 特定使用者 | `@user_name` |   |   |
  17. | 特定人群 | `@group_name` |   |   |
  18. | 整个团队 | `@all` |   |   |
  19. | project | `namespace/project>` |   |   |
  20. | issue | `#123` | `namespace/project#123` | `project#123` |
  21. | 合并要求 | `!123` | `namespace/project!123` | `project!123` |
  22. | snippet | `$123` | `namespace/project$123` | `project$123` |
  23. | epic | `&123` | `group1/subgroup&123` |   |
  24. | 通过 ID 标签 | `~123` | `namespace/project~123` | `project~123` |
  25. | 一词标签名称 | `~bug` | `namespace/project~bug` | `project~bug` |
  26. | 多词标签名称 | `~"feature request"` | `namespace/project~"feature request"` | `project~"feature request"` |
  27. | 范围标签按名称 | `~"priority::high"` | `namespace/project~"priority::high"` | `project~"priority::high"` |
  28. | ID 项目里程碑 | `%123` | `namespace/project%123` | `project%123` |
  29. | 一词里程碑 | `%v1.23` | `namespace/project%v1.23` | `project%v1.23` |
  30. | 多词里程碑 | `%"release candidate"` | `namespace/project%"release candidate"` | `project%"release candidate"` |
  31. | 具体提交 | `9ba12248` | `namespace/project@9ba12248` | `project@9ba12248` |
  32. | 提交范围比较 | `9ba12248...b19a04f5` | `namespace/project@9ba12248...b19a04f5` | `project@9ba12248...b19a04f5` |
  33. | 仓库文件参考 | `[README](doc/README)` |   |   |
  34. | 存储库文件行参考 | `[README](doc/README#L13)` |   |   |
  36. 除此之外，还可以识别和格式化指向某些对象的链接. 这些示例包括：
  38. *   对问题的评论： `"https://gitlab.com/gitlab-org/gitlab/-/issues/1234#note_101075757"` ，它将呈现为`#1234 (note1)`
  39. *   问题设计标签： `"https://gitlab.com/gitlab-org/gitlab/-/issues/1234/designs"` ，该标签将显示为`#1234 (designs)` .
  40. *   链接到各个设计： `"https://gitlab.com/gitlab-org/gitlab/-/issues/1234/designs/layout.png"` ，它将呈现为`#1234[layout.png]` .
  42. ### Task lists[](#task-lists "Permalink")
  44. > 如果未正确呈现，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#task-lists) .
  48. 要创建任务列表，请添加特殊格式的 Markdown 列表. 您可以使用无序列表或有序列表：
  • Completed task
  • Incomplete task
    • Sub-task 1
    • Sub-task 2
    • Sub-task 3
    1. Completed task
  1. Incomplete task
    1. Sub-task 1
    2. Sub-task 2 ```
  • 完成的任务
  • []未完成的任务
    • []子任务 1
    • 子任务 2
    • []子任务 3
  1. Completed task
  2. []未完成的任务
    1. []子任务 1
    2. 子任务 2

通过在标记行[[_TOC_]]上添加标记，您可以将目录添加到 Markdown 文件，Wiki 页面或发布/合并请求描述中. 它将显示为链接到各种标题的无序列表.

  1. This is an intro sentence to my Wiki page.
  3. [[_TOC_]]
  5. ## My first heading
  7. First section content.
  9. ## My second heading
  11. Second section content.

Wiki-specific Markdown

以下示例显示了 Wiki 内部链接的行为.

Wiki - direct page link

仅包含页面的子弹的链接将指向该页面， 位于 Wiki 的基本级别 .

该代码段将链接到 Wiki 根目录下的documentation页面：

  1. [Link to Documentation](documentation)

Wiki - direct file link

相对于当前页面 ，带有文件扩展名的链接指向该文件.

如果下面的代码段放在<your_wiki>/documentation/related的页面上，它将链接到<your_wiki>/documentation/file.md ：

  1. [Link to File](file.md)

Wiki - hierarchical link

可以使用./<page> ， ../<page>来相对于当前 Wiki 页面构建链接.

如果此代码段放在<your_wiki>/documentation/main的页面上，它将链接到<your_wiki>/documentation/related ：

  1. [Link to Related Page](./related)

如果此代码段放在<your_wiki>/documentation/related/content的页面上，它将链接到<your_wiki>/documentation/main ：

  1. [Link to Related Page](../main)

如果此代码段放在<your_wiki>/documentation/main的页面上，它将链接到<your_wiki>/documentation/related.md ：

  1. [Link to Related Page](./related.md)

如果此代码段放在<your_wiki>/documentation/related/content的页面上，它将链接到<your_wiki>/documentation/main.md ：

Wiki - root link

该代码段链接到<wiki_root>/documentation ：

  1. [Link to Related Page](/documentation)

该代码段链接到<wiki_root>/miscellaneous.md ：

  1. [Link to Related Page](/miscellaneous.md)

Embedding metrics in GitLab Flavored Markdown

公制图表可以嵌入到 GitLab 风味 Markdown 中. 有关更多详细信息，请参见在 GitLab 风格的 Markdown 中嵌入度量标准 .

Standard Markdown and extensions in GitLab

所有标准 Markdown 格式均应在 GitLab 中按预期工作. 一些标准功能通过附加功能进行了扩展，而不会影响标准用法. 如果扩展了功能，则新选项将作为子节列出.

Blockquotes

块引号是突出显示信息（如边注）的简便方法. 它是通过以>开头的 blockquote 行来生成的：

  1. > Blockquotes are very handy to emulate reply text.
  2. > This line is part of the same quote.
  4. Quote break.
  5.  > This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote.

块引用非常容易模拟回复文本. 该行是同一报价的一部分.

报价中断.

这是一条很长的行，当它换行时仍会被正确引用. 哦，男孩，让我们继续写作，以确保它足够长，可以实际包裹所有人. 哦，您可以将 Markdown放入 blockquote 中.

Multiline blockquote

GFM 还支持>>>围起来的多行块引用，从而扩展了标准的 Markdown 标准：

  1. >>>
  2. If you paste a message from somewhere else
  4. that spans multiple lines,
  6. you can quote that without having to manually prepend `>` to every line!
  7. >>>

如果您从其他地方粘贴消息

跨越多行，

您可以引用它，而不必手动在每行前面加上> ！

Code spans and blocks

您可以轻松突出显示应视为代码而非简单文本的任何内容.

简单的内联代码很容易用单个反引号```突出显示：

  1. Inline `code` has `back-ticks around` it.

Inline code has back-ticks around it.

同样，整个代码块可以用三个反引号（ ```` ），三个波浪号（~~~` ）或缩进 4 个或更多的空格来围起来，以实现较大代码体的相似效果.

  1. ```python def function():
  2.     #indenting works just fine in the fenced code block
  3.     s = "Python code"
  4.     print s
  5. ``` Using 4 spaces
  6.     is like using
  7.     3-backtick fences.
  1. ~~~
  2. Tildes are OK too.
  3. ~~~

上面的三个示例呈现为：

  1. def function():
  2.     #indenting works just fine in the fenced code block
  3.     s = "Python code"
  4.     print s
  1. Using 4 spaces
  2. is like using
  3. 3-backtick fences.
  1. Tildes are OK too.

Colored code and syntax highlighting

如果未正确呈现，请在 GitLab 本身中查看它 .

GitLab 使用在代码块中突出显示了更加丰富多彩的语法. 有关支持的语言的列表，请访问Rouge 项目 Wiki . 语法突出显示仅在代码块中受支持，因此在内联时无法突出显示代码.

代码块由带有三个反引号（ ```` ）或三个波浪号（~~~` ）的行围起来，并在第一个围栏的末尾标识了语言：

  1. ```javascript var s = "JavaScript syntax highlighting";
  2. alert(s);

```python def function():

  1. #indenting works just fine in the fenced code block
  2. s = "Python syntax highlighting"
  3. print s
  2. ```ruby require 'redcarpet'
  3. markdown = Redcarpet.new("Hello World!")
  4. puts markdown.to_html

``` No language indicated, so no syntax highlighting. s = “There is no highlighting for this.” But let’s throw in a tag.

  1. ```
  3. 上面的四个示例呈现为：

var s = “JavaScript syntax highlighting”; alert(s);

def function():

  1. #indenting works just fine in the fenced code block
  2. s = "Python syntax highlighting"
  3. print s

require ‘redcarpet’ markdown = Redcarpet.new(“Hello World!”) puts markdown.to_html

No language indicated, so no syntax highlighting. s = “There is no highlighting for this.” But let’s throw in a tag. 

  2. ### Emphasis[](#emphasis "Permalink")
  4. 在 Markdown 中有多种强调文本的方法. 您可以斜体，粗体，删除线，以及将这些强调样式结合在一起.
  6. Examples:

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with double asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this. 

  2. 强调，又称斜体，带有*星号*或*下划线* .
  4. 重点突出，又大胆，带有双星**号**或**下划线** .
  6. 结合强调与**星号和*下划线*** .
  8. 删除线使用两个波浪号. ~~抓这个.~~
  10. **注意：**删除线不是 Markdown 核心标准的一部分，而是 GFM 的一部分.
  12. #### Multiple underscores in words and mid-word emphasis[](#multiple-underscores-in-words-and-mid-word-emphasis "Permalink")
  14. > 如果未正确呈现，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#multiple-underscores-in-words) .
  16. 仅将单词的*一部分*斜体化通常是没有用的，尤其是当您要处理经常带有多个下划线的代码和名称时. 结果，GFM 通过忽略单词中的多个下划线来扩展了标准的 Markdown 标准，以更好地呈现讨论代码的 Markdown 文档：

perform_complicated_task

do_this_and_do_that_and_another_thing

butemphasis is_desired _here 

  2. perform_complicated_task
  4. do_this_and_do_that_and_another_thing
  6. 但是*在这里需要重点*
  8. * * *
  10. 如果您只想强调单词的一部分，仍然可以使用星号来完成：

performcomplicatedtask

dothisanddothatandanother thing 

  2. perform*complicated*task
  4. 做*这个* ， *做*那个*和*另一件事
  6. ### Footnotes[](#footnotes "Permalink")
  8. 脚注会添加指向注释的链接，该链接将在 Markdown 文件的末尾呈现.
  10. 要创建脚注，您既需要参考标记，又需要带有注释内容的单独行（文件中的任何地方）.
  12. 无论标签名称如何，参考标签的相对顺序都决定了呈现的编号.
  14. 参考标记可以使用字母和其他字符. 在解决[此错误](https://gitlab.com/gitlab-org/gitlab/-/issues/24423)之前，请避免在脚注标签名称中使用小写`w`或下划线（ `_` ）.

A footnote reference tag looks like this: [^1]

This reference tag is a mix of letters and numbers. [^footnote-42]

[^1]: This is the text inside a footnote.

[^footnote-42]: This is another footnote.

H1

H3

H4

H5
H6

Alternatively, for H1 and H2, an underline-ish style:

Alt-H1

Alt-H2

  2. #### Header IDs and links[](#header-ids-and-links "Permalink")
  4. GFM 扩展了标准 Markdown 标准，以便所有 Markdown 呈现的标头都自动获取 ID，可以将 ID 链接到该 ID，注释中除外.
  6. 悬停时，将显示到这些 ID 的链接，从而可以更轻松地将链接复制到标头以在其他地方使用.
  8. 根据以下规则从标头的内容生成 ID：
  10. 1.  所有文本都将转换为小写.
  11. 2.  删除所有非单词文本（例如标点符号或 HTML）.
  12. 3.  所有空格都将转换为连字符.
  13. 4.  连续的两个或多个连字符转换为 1.
  15. Example:

This header has spaces in it

This header has a :thumbsup: in it

This header has Unicode in it: 한글

This header has 3.5 in it (and parentheses)

  2. 将生成以下链接 ID：
  4. 1.  `this-header-has-spaces-in-it`
  5. 2.  `this-header-has-a-in-it`
  6. 3.  `this-header-has-unicode-in-it-한글`
  7. 4.  `this-header-has-spaces-in-it-1`
  8. 5.  `this-header-has-spaces-in-it-2`
  9. 6.  `this-header-has-3-5-in-it-and-parentheses`
  11. 请注意，表情符号处理是在生成标题 ID 之前进行的，因此表情符号将转换为图像，然后从 ID 中删除.
  13. ### Horizontal Rule[](#horizontal-rule "Permalink")
  15. 使用三个或多个连字符，星号或下划线来创建水平尺非常简单：

Three or more hyphens,

asterisks,

or underscores

  2. ### Images[](#images "Permalink")
  4. Examples:

Inline-style (hover to see title text):

alt text

Reference-style (hover to see title text):

  2. Inline-style (hover to see title text):
  4. [![alt text](/projects/gitlab-doc-zh/docs//projects/gitlab-doc-zh/docs/img/c5c16791538bd6838d6196a0b4ec5bb7.png "Title Text")]($docs-img-markdown_logo.png)
  6. 参考样式（悬停以查看标题文本）：
  8. [![alt text](/projects/gitlab-doc-zh/docs//projects/gitlab-doc-zh/docs/img/c5c16791538bd6838d6196a0b4ec5bb7.png "Title Text")]($docs-img-markdown_logo.png)
  10. #### Videos[](#videos "Permalink")
  12. > 如果未正确呈现，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#videos) .
  14. 链接到带有视频扩展名的文件的图像标签会自动转换为视频播放器. 有效的视频扩展名是`.mp4` ， `.m4v` ， `.mov` ， `.webm`和`.ogv` ：

Here’s a sample video:

Sample Video 

  2. 这是一个示例视频：
  4. [![Sample Video](/projects/gitlab-doc-zh/docs/img/bf99e217a01388f7c11df39626ab9e22.png)]($docs-img-markdown_video.mp4)
  6. #### Audio[](#audio "Permalink")
  8. > 如果未正确呈现，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#audio) .
  10. 与视频类似，带有音频扩展名的文件的链接标签会自动转换为音频播放器. 有效的音频扩展名是`.mp3` ， `.oga` ， `.ogg` ， `.spx`和`.wav` ：

Here’s a sample audio clip:

  2. 这是一个示例音频剪辑：
  4. [![Sample Audio](/projects/gitlab-doc-zh/docs/img/8095440bd29d634de897ae56f76a4969.png)]($docs-img-markdown_audio.mp3)
  6. ### Inline HTML[](#inline-html "Permalink")
  8. > 要在第二个示例中[查看](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html)在 HTML 中呈现的 Markdown，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html) .
  10. 您还可以在 Markdown 中使用原始 HTML，通常效果很好.
  12. 有关允许的 HTML 标记和属性的列表，请参见 HTML :: Pipeline 的[SanitizationFilter](https://github.com/jch/html-pipeline/blob/v2.12.3/lib/html/pipeline/sanitization_filter.rb#L42)类的文档. 除了默认`SanitizationFilter`允许列表，GitLab 允许`span` ， `abbr` ， `details`和`summary`元素.

Definition list
Is something people use sometimes.

Markdown in HTML
Does not work very well. HTML tags will work, in most cases.

  2. Definition list
  4. 人们有时会用到的东西.
  6. Markdown in HTML
  8. *不是*很好**. HTML *标签*将工作 ，在大多数情况下.
  10. * * *
  12. 仍然可以在 HTML 标记内使用 Markdown，但前提是包含 Markdown 的行分为各自的行：
Markdown in HTML
Does not work very well. HTML tags will work, in most cases.

Markdown in HTML

Does not work very well. HTML tags will work, in most cases.

  2. Markdown in HTML
  4. *不是*很好**. HTML 标记在大多数情况下都可以使用.
  6. Markdown in HTML
  8. *不能* 很好地工作. HTML 标记在大多数情况下都可以使用.
  10. #### Details and summary[](#details-and-summary "Permalink")
  12. > 要在第二个示例中[查看](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#details-and-summary)在 HTML 中呈现的 Markdown，请[在 GitLab 本身中查看它](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#details-and-summary) .
  14. 可以使用 HTML 的[`<details>`](https://s0developer0mozilla0org.icopy.site/en-US/docs/Web/HTML/Element/details)和[`<summary>`](https://s0developer0mozilla0org.icopy.site/en-US/docs/Web/HTML/Element/summary)标记折叠内容. 这对于折叠长日志特别有用，因为它们占用更少的屏幕空间.

Click this to collapse/fold. These details will remain hidden until expanded. 
  1. PASTE LOGS HERE

<details title="单击以折叠/折叠. These details will remain hidden until expanded. PASTE LOGS HERE"><summary>单击以折叠/折叠.</summary> 这些细节*将*保持**隐藏，**直到扩展. PASTE LOGS HERE ```

这些标记内的 Markdown 也受支持.

注意：如果 Markdown 无法正确呈现，请尝试在页面顶部添加{::options parse_block_html="true" /} ，然后将markdown="span"添加到开头的摘要标记中，如下所示： <summary markdown="span"> .

请记住，在</summary>标记之后和</details>标记之前留空行，如示例所示：

  1. <details>
  2. <summary>Click this to collapse/fold.</summary>
  4. These details _will_ remain **hidden** until expanded.

PASTE LOGS HERE

  2. </details>
单击以折叠/折叠. 这些细节将保持隐藏，直到扩展. PASTE LOGS HERE

Line breaks

如果先前的文本以两个换行符结尾，则会插入一个换行符（将开始一个新的段落），例如当您连续两次按Enter 键时. 如果仅使用一个换行符（ 按一次Enter 键 ），则下一个句子将成为同一段落的一部分. 如果要避免长行换行并使它们易于编辑，这很有用：

  1. Here's a line for us to start with.
  3. This longer line is separated from the one above by two newlines, so it will be a *separate paragraph*.
  5. This line is also a separate paragraph, but...
  6. These lines are only separated by single newlines,
  7. so they *do not break* and just follow the previous lines
  8. in the *same paragraph*.

这是我们要开始的一行.

该较长的行与上面的一行由两个换行符隔开 ，因此它将是一个单独的段落 .

该行也是一个单独的段落，但是…这些行仅由单个换行符分隔，因此它们不会中断并且仅遵循同一段落中的前几行.

Newlines

GFM 在遵循 Markdown 规范.

段落是一个或多个连续的文本行，由一个或多个空行分隔（第一段末尾有两个新行）， 如上所述 .

如果您需要对换行符或换行符进行更多控制，则可以通过以反斜杠或两个或多个空格结束一行来添加单个换行符. 连续两个换行符将创建一个新的段落，中间有一个空行：

  1. First paragraph.
  2. Another line in the same paragraph.
  3. A third line in the same paragraph, but this time ending with two spaces.{space}{space}
  4. A new line directly under the first paragraph.
  6. Second paragraph.
  7. Another line, this time ending with a backslash.\
  8. A new line due to the previous backslash.

Links

有两种创建链接的方法，即内联样式和引用样式：

  1. - This is an [inline-style link](https://www.google.com)
  2. - This is a [link to a repository file in the same directory]($docs-index.md)
  3. - This is a [relative link to a readme one directory higher]($README.md)
  4. - This is a [link that also has title text](https://www.google.com "This link takes you to Google!")
  6. Using header ID anchors:
  8. - This links to [a section on a different Markdown page, using a "#" and the header ID]($docs-index.md#overview)
  9. - This links to [a different section on the same page, using a "#" and the header ID](#header-ids-and-links)
  11. Using references:
  13. - This is a [reference-style link, see below][Arbitrary case-insensitive reference text]
  14. - You can [use numbers for reference-style link definitions, see below][1]
  15. - Or leave it empty and use the [link text itself][], see below.
  17. Some text to show that the reference links can follow later.
  19. [arbitrary case-insensitive reference text]: https://www.mozilla.org/en-US/
  20. [1]: https://slashdot.org
  21. [link text itself]: https://www.reddit.com

使用标头 ID 锚点：

使用参考：

一些文本表明参考链接可以在以后使用.

注意：相对链接不允许引用 Wiki 页面或项目文件中的 Wiki 页面中的项目文件. 这样做的原因是，Wiki 始终位于 GitLab 中的单独 Git 存储库中. 例如，仅当链接位于 Wiki Markdown 文件内部时， [I'm a reference-style link](style)才会将链接指向wikis/style .

URL auto-linking

GFM will auto-link almost any URL you put into your text:

  1. - https://www.google.com
  2. - https://www.google.com
  3. - ftp://ftp.us.debian.org/debian/
  4. - smb://foo/bar/baz
  5. - irc://irc.freenode.net/
  6. - http://localhost:3000

Lists

可以轻松创建有序列表和无序列表.

对于有序列表，请在有序列表的每一行的开头添加希望列表以其开头的数字，例如1. ，后跟一个空格. 在第一个数字之后，使用什么数字都没有关系，有序列表将按垂直顺序自动编号，因此对同一列表中的所有项目重复1. .. 如果你开始以外的其他数字1. ，它会用它作为第一个数字，并从那里计数.

Examples:

  1. 1. First ordered list item
  2. 2. Another item
  3.  - Unordered sub-list.
  4. 1. Actual numbers don't matter, just that it's a number
  5.  1. Ordered sub-list
  6.  1. Next ordered sub-list item
  7. 4. And another item.
  1. 首先订购的清单项目
  2. 另一个项目
    • 无序子列表.
  3. 实际数字并不重要，只是一个数字
    1. 订购子清单
    2. 下一个订购的子清单项目
  4. 还有另一个项目.

对于无序列表，请在无序列表的每一行的开头添加- ， *或+ ，然后加上一个空格，但是您不能混合使用它们.

  1. Unordered lists can:
  2.  - use
  3. - minuses
  5. They can also:
  6.  * use
  7. * asterisks
  9. They can even:
  10.  + use
  11. + pluses

无序列表可以：

  • use
  • minuses

他们还可以：

  • use
  • asterisks

They can even:

  • use
  • pluses

如果列表项包含多个段落，则每个后续段落都应缩进到与列表项文本开头相同的级别.

Example:

  1. 1. First ordered list item
  3.    Second paragraph of first item.
  4.  1. Another item

  1. 首先订购的清单项目

    第一项第二段.

  2. Another item

如果第一项的段落没有缩进适当的空格数，则该段落将出现在列表外部，而不是在列表项下方正确缩进.

Example:

  1. 1. First ordered list item
  3.   Paragraph of first item.
  4.  1. Another item
  1. 首先订购的清单项目

第一项的段落.

  1. 另一个项目

Superscripts / Subscripts

当前，CommonMark 和 GFM 不支持 Redcarpet 支持的上标语法（ x^2 ）. 您可以对上标和下标使用标准的 HTML 语法：

  1. The formula for water is H<sub>2</sub>O
  2. while the equation for the theory of relativity is E = mc<sup>2</sup>.

水的公式为 H 2 O，而相对论的公式为 E = mc 2 .

Tables

表不是 Markdown 核心规范的一部分，但它们是 GFM 的一部分.

  1. 第一行包含标头，并用”竖线”（ | ）分隔.
  2. 第二行将标题与单元格分开，并且必须包含三个或更多破折号.
  3. 第三行以及随后的任何行均包含单元格值.
    • 您不能在 Markdown 中将单元格分隔成多行，它们必须保持为单行，但它们可能会很长. 如果需要，还可以包含 HTML <br>标记以强制换行.
    • 像元大小不必彼此匹配. 它们很灵活，但必须用管道（ | ）分隔.
    • 您可以有空白单元格.

Example:

  1. | header 1 | header 2 | header 3 |
  2. | ---      |  ------  |---------:|
  3. | cell 1   | cell 2   | cell 3   |
  4. | cell 4 | cell 5 is longer | cell 6 is much longer than the others, but that's ok. It will eventually wrap the text when the cell is too large for the display size. |
  5. | cell 7   |          | cell <br> 9 |

9 |

（另外，你可以通过添加冒号选择文本列中的对齐:第二行中的”破折号”线条的两侧）. 这将影响列中的每个单元格.

注意： 在 GitLab 本身中 ，标题始终在 Chrome 和 Firefox 中左对齐，并在 Safari 中居中.

  1. | Left Aligned | Centered | Right Aligned | Left Aligned | Centered | Right Aligned |
  2. | :---         | :---:    | ---:          | :----------- | :------: | ------------: |
  4. | Cell 7       | Cell 8   | Cell 9        | Cell 10      | Cell 11  | Cell 12       |

Copy from spreadsheet and paste in Markdown

在 GitLab 12.7 中引入 .

如果您使用电子表格软件（例如 Microsoft Excel，Google 表格或 Apple Numbers），则可以从电子表格中进行复制，GitLab 会将其粘贴为 Markdown 表. 例如，假设您具有以下电子表格：

选择单元格并将其复制到剪贴板. 打开一个 GitLab Markdown 条目并粘贴电子表格：

  • 该文档从大量利用.
  • Daring Fireball 上的原始Markdown 语法指南是详细解释标准 Markdown 的绝佳资源.
  • 有关 CommonMark 的详细规范，请参见
  • CommonMark Dingus是用于测试 CommonMark 语法的便捷工具.

  1. 这是脚注中的文本.

  2. 这是另一个脚注. ↩