InfoGrab DocsInfoGrab Docs

GitLab Flavored Markdown (GLFM)

요약

GitLab Flavored Markdown(GLFM)은 GitLab 사용자 인터페이스에서 텍스트 서식을 지정하는 마크업 언어입니다. GitLab UI에 텍스트를 입력하면 GitLab은 해당 텍스트가 GitLab Flavored Markdown이라고 가정합니다.

GitLab Flavored Markdown(GLFM)은 GitLab 사용자 인터페이스에서 텍스트 서식을 지정하는 마크업 언어입니다. GLFM은 다음을 제공합니다.

  • 코드, 다이어그램, 수식, 멀티미디어를 지원하여 풍부한 콘텐츠를 만듭니다.
  • 상호 참조로 이슈, 머지 리퀘스트 등 GitLab 콘텐츠를 연결합니다.
  • 작업 목록, 표, 접을 수 있는 섹션으로 정보를 구성합니다.
  • 100개가 넘는 프로그래밍 언어의 구문 강조를 지원합니다.
  • 의미 있는 제목 구조와 이미지 설명으로 접근성을 확보합니다.

GitLab UI에 텍스트를 입력하면 GitLab은 해당 텍스트가 GitLab Flavored Markdown이라고 가정합니다.

GitLab Flavored Markdown은 다음 위치에서 사용할 수 있습니다.

  • 댓글
  • 이슈
  • 에픽
  • 머지 리퀘스트
  • 마일스톤
  • 스니펫(스니펫 이름에 .md 확장자가 있어야 합니다)
  • 위키 페이지
  • 리포지터리 안의 Markdown 문서
  • 릴리스

GitLab에서는 다른 서식 있는 텍스트 파일도 사용할 수 있습니다. 이를 위해 의존성을 설치해야 할 수 있습니다. 자세한 내용은 gitlab-markup gem 프로젝트를 참고합니다.

Note

이 Markdown 사양은 GitLab에서만 유효합니다. 여기에서도 Markdown을 최대한 충실하게 렌더링하지만, GitLab 문서 웹사이트와 GitLab 핸드북은 다른 Markdown 렌더러를 사용합니다.

이 예제들을 GitLab이 정확히 어떻게 렌더링하는지 확인하려면 다음과 같이 합니다.

  1. 해당 원본 Markdown 예제를 복사합니다(렌더링된 예제가 아닙니다).
  2. Markdown 미리 보기를 지원하는 GitLab의 임의 위치(예: 이슈나 머지 리퀘스트의 댓글 또는 설명, 새 Markdown 파일)에 Markdown을 붙여넣습니다.
  3. Preview를 선택하여 GitLab이 렌더링한 Markdown을 확인합니다.

표준 Markdown과의 차이#

GitLab Flavored Markdown은 다음으로 구성됩니다.

모든 표준 Markdown 서식은 GitLab에서 예상대로 동작합니다. 일부 표준 기능은 표준 사용 방식에 영향을 주지 않으면서 추가 기능으로 확장되어 있습니다.

다음 기능은 표준 Markdown에 없습니다.

다음 기능은 표준 Markdown에서 확장되었습니다.

Markdown과 접근성#

GitLab Flavored Markdown을 사용하면 디지털 콘텐츠를 만들게 됩니다. 이 콘텐츠는 독자가 최대한 접근할 수 있어야 합니다. 다음 목록이 전부는 아니지만, 특히 주의해야 할 GitLab Flavored Markdown 스타일에 대한 지침을 제공합니다.

접근성을 갖춘 제목#

제목 서식을 사용하여 논리적인 제목 구조를 만듭니다. 페이지의 제목 구조는 잘 만든 목차처럼 이해가 되어야 합니다. 페이지에 h1 요소가 하나만 있고, 제목 수준을 건너뛰지 않으며, 올바르게 중첩되도록 합니다.

접근성을 갖춘 표#

표를 접근하기 쉽고 훑어보기 쉽게 유지하려면 표에 빈 셀이 없어야 합니다. 셀에 넣을 의미 있는 값이 없다면 "N/A" 또는 "None"을 입력하는 것을 고려합니다.

접근성을 갖춘 이미지와 동영상#

[alt text]에 이미지나 동영상을 설명합니다. 설명은 정확하고, 간결하며, 고유해야 합니다. 설명에 image of 또는 video of를 쓰지 않습니다. 자세한 내용은 WebAim 대체 텍스트를 참고합니다.

작업 항목 및 머지 리퀘스트 제목#

히스토리
  • GitLab Flavored Markdown 전체 지원이 GitLab 18.0에서 도입되었습니다.
  • GitLab Flavored Markdown 전체 지원이 GitLab 18.11에서 제거되었습니다.

이슈, 머지 리퀘스트, 에픽 및 기타 작업 항목의 제목은 GitLab Flavored Markdown을 전체 지원하지 않습니다. 제목에서 지원하는 것은 다음뿐입니다.

  • 코드 스팬(`code`). 백틱 추가 사용이나 이스케이프는 지원되지 않습니다.
  • 이모지(:emoji: 단축 코드와 사용자 지정 이모지).
  • 자동 링크되는 URL.
  • #123, @user, !456 같은 GitLab 전용 참조.

굵게, 기울임, 링크, 제목, 목록 등 표준 Markdown 구문과 그 밖의 블록 수준 서식은 제목에서 처리되지 않습니다. 예를 들어 제목 **Merge request title**은 굵게 표시되지 않고 별표가 그대로 표시됩니다.

제목#

#을 사용하여 1부터 6까지의 제목을 만듭니다.

# H1
## H2
### H3
#### H4
##### H5
###### H6

또는 H1과 H2는 밑줄 스타일을 사용할 수 있습니다.

Alt-H1
======

Alt-H2
------

제목 앵커#

히스토리
  • 제목 링크 생성 방식이 GitLab 17.0에서 변경되었습니다.

GitLab은 모든 Markdown 제목에 앵커를 자동으로 추가하므로 해당 제목으로 링크할 수 있습니다.

마우스를 올리면 해당 앵커로 연결되는 링크가 표시되어, 제목 링크를 복사해 다른 곳에서 사용하기 쉽습니다.

앵커는 다음 규칙에 따라 제목 내용에서 생성됩니다.

  1. 모든 텍스트를 소문자로 변환합니다.
  2. 문자, 숫자, 하이픈, 밑줄을 제외한 모든 문자를 제거합니다.
  3. 모든 공백을 하이픈으로 변환합니다.
  4. 같은 앵커의 제목이 이미 생성되었다면, 1부터 시작하는 고유한 증가 번호를 덧붙입니다.

예:

# This heading has spaces in it
## This heading has a :thumbsup: in it
# This heading has Unicode in it: 한글
## This heading has spaces in it
### This heading has spaces in it
## This heading has 3.5 in it (and parentheses)
## This heading has  multiple spaces and --- hyphens_and_underscores

이 예제는 다음 제목 앵커를 생성합니다.

  1. #this-heading-has-spaces-in-it
  2. #this-heading-has-a-thumbsup-in-it
  3. #this-heading-has-unicode-in-it-한글
  4. #this-heading-has-spaces-in-it-1
  5. #this-heading-has-spaces-in-it-2
  6. #this-heading-has-35-in-it-and-parentheses
  7. #this-heading-has--multiple-spaces-and-----hyphens_and_underscores

스니펫에서는 여러 파일 사이에서 앵커가 충돌하지 않도록 제목에 파일 이름에서 유래한 접두사도 붙습니다. 예를 들어 README.md 파일의 ## TL;DR 제목은 #tldr이 아니라 #readme-tldr 앵커를 갖습니다.

줄 바꿈#

앞의 텍스트가 개행 두 번으로 끝나면 줄 바꿈이 삽입됩니다(새 문단이 시작됩니다). 예를 들어 Enter를 연속으로 두 번 누른 경우입니다. 개행을 한 번만(Enter를 한 번만 눌러) 사용하면 다음 문장은 같은 문단에 속한 상태로 남습니다. 긴 줄이 줄 바꿈되지 않게 하면서 편집하기 쉽게 유지하려면 이 방식을 사용합니다.

Here's a line for us to start with.

This longer line is separated from the one above by two newlines, so it is a *separate paragraph*.

This line is also a separate paragraph, but...
These lines are only separated by single newlines,
so they *do not break* and just follow the previous lines
in the *same paragraph*.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Here's a line for us to start with.

This longer line is separated from the one above by two newlines, so it is a separate paragraph.

This line is also a separate paragraph, but... These lines are only separated by single newlines, so they do not break and just follow the previous lines in the same paragraph.

개행#

문단은 줄 바꿈에서 설명한 대로, 하나 이상의 빈 줄(첫 문단 끝의 개행 두 번)로 구분된 하나 이상의 연속된 텍스트 줄입니다.

줄 바꿈이나 소프트 리턴을 더 세밀하게 제어해야 하는 경우, 줄 끝에 백슬래시나 공백 두 개 이상을 넣으면 줄 바꿈이 하나 추가됩니다. 개행이 연속으로 두 번 있으면 사이에 빈 줄이 있는 새 문단이 만들어집니다.

First paragraph.
Another line in the same paragraph.
A third line in the same paragraph, but this time ending with two spaces.<space><space>
A new line directly under the first paragraph.

Second paragraph.
Another line, this time ending with a backslash.\
A new line due to the previous backslash.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

First paragraph. Another line in the same paragraph. A third line in the same paragraph, but this time ending with two spaces.
A new line directly under the first paragraph.

Second paragraph. Another line, this time ending with a backslash.
A new line due to the previous backslash.

이 구문은 문단과 줄 바꿈 처리에 관한 Markdown 사양을 따릅니다.

강조#

텍스트는 여러 방법으로 강조할 수 있습니다. 기울임, 굵게, 취소선을 사용하거나 이러한 강조 스타일을 함께 조합합니다.

예:

Emphasis, or italics, with *asterisks* or _underscores_.

Strong emphasis, or bold, with double **asterisks** or __underscores__.

Combined emphasis with **asterisks and _underscores_**.

Strikethrough with double tildes. ~~Scratch this.~~

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Emphasis, or italics, with asterisks or underscores.

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

Combined emphasis with asterisks and underscores.

Strikethrough with double tildes. Scratch this.

단어 중간의 강조#

단어의 일부만 기울임 처리하는 것은 피합니다. 특히 밑줄이 여러 개 자주 나오는 코드와 이름을 다룰 때 그렇습니다.

GitLab Flavored Markdown은 코드를 다루는 Markdown 문서가 더 잘 렌더링되도록 단어 안의 여러 밑줄을 무시합니다.

perform_complicated_task

do_this_and_do_that_and_another_thing

but_emphasis is_desired _here_

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

perform_complicated_task

do_this_and_do_that_and_another_thing

but_emphasis is_desired here

단어의 일부만 강조하려면 별표를 사용하면 됩니다.

perform*complicated*task

do*this*and*do*that*and*another thing

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

performcomplicatedtask

dothisanddothatandanother thing

인라인 diff#

인라인 diff 태그를 사용하면 {+ additions +} 또는 [- deletions -]를 표시할 수 있습니다.

감싸는 태그는 중괄호나 대괄호 중 어느 쪽이든 사용할 수 있습니다.

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

GitLab 인터페이스에서 렌더링된 인라인 diff


그러나 감싸는 태그를 섞어 쓸 수는 없습니다.

- {+ addition +]
- [+ addition +}
- {- deletion -]
- [- deletion -}

diff 강조는 `inline code`에서는 동작하지 않습니다. 텍스트에 백틱(`)이 포함되어 있다면 각 백틱을 백슬래시 \로 이스케이프합니다.

- {+ Just regular text +}
- {+ Text with `backticks` inside +}
- {+ Text with escaped \`backticks\` inside +}

혼합 서식이 적용된 인라인 diff를 GitLab 인터페이스에서 렌더링한 모습

가로줄#

하이픈, 별표, 밑줄을 세 개 이상 사용하여 가로줄을 만듭니다.

---

***

___

렌더링하면 모든 가로줄은 다음과 비슷하게 표시됩니다.


목록#

순서 있는 목록과 순서 없는 목록을 만들 수 있습니다.

순서 있는 목록은 각 줄의 시작에 목록을 시작하려는 숫자(예: 1.)와 공백을 차례로 추가합니다. 첫 번째 숫자 이후에는 어떤 숫자를 써도 상관없습니다. 순서 있는 목록은 세로 순서대로 자동 번호가 매겨지므로, 같은 목록의 모든 항목에 1.을 반복해서 쓰는 것이 일반적입니다. 1.이 아닌 숫자로 시작하면 그 숫자를 첫 번째 숫자로 사용하고 거기서부터 하나씩 늘려 갑니다.

예:

1. First ordered list item
2. Another item
   - Unordered sub-list.
1. Actual numbers don't matter, just that it's a number
   1. Ordered sub-list
   1. Next ordered sub-list item
4. And another item.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
    2. Next ordered sub-list item
  4. And another item.

순서 없는 목록은 각 줄의 시작에 -, *, + 중 하나와 공백을 차례로 추가합니다. 같은 목록에서 이 문자들을 섞어 쓰지 않습니다.

Unordered lists can:

- use
- minuses

They can also:

* use
* asterisks

They can even:

+ use
+ pluses

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Unordered lists can:

  • use
  • minuses

They can also:

  • use
  • asterisks

They can even:

  • use
  • pluses

목록 항목에 문단이 여러 개 있으면 이후의 각 문단을 들여써서

목록 항목 텍스트가 시작하는 위치와 같은 수준에 맞춰야 합니다.

예:

1. First ordered list item

   Second paragraph of first item.

1. Another item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  1. First ordered list item

    Second paragraph of first item.

  2. Another item

첫 번째 항목의 문단을 올바른 개수의 공백으로 들여쓰지 않으면 그 문단은 목록 밖에 표시됩니다. 목록 항목 아래에 올바르게 들여쓰려면 정확한 개수의 공백을 사용합니다. 예:

1. First ordered list item

  (Misaligned paragraph of first item.)

1. Another item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  1. First ordered list item

(Misaligned paragraph of first item.)

  1. Another item

순서 있는 목록이 순서 없는 목록 항목의 첫 번째 하위 항목이고 1.로 시작하지 않는다면, 앞에 빈 줄이 있어야 합니다.

예를 들어 빈 줄이 있는 경우는 다음과 같습니다.

- Unordered list item

  5. First ordered list item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  • Unordered list item

    1. First ordered list item

빈 줄이 없으면 두 번째 목록 항목이 첫 번째 항목의 일부로 렌더링됩니다.

- Unordered list item
  5. First ordered list item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  • Unordered list item 5. First ordered list item

CommonMark는 순서 있는 목록 항목과 순서 없는 목록 항목 사이의 빈 줄을 무시하고, 이를 하나의 목록으로 간주합니다. 항목은 느슨한 목록으로 렌더링됩니다. 각 목록 항목이 문단 태그로 둘러싸이므로 문단 간격과 여백이 적용됩니다. 그래서 목록의 각 항목 사이에 여분의 간격이 있는 것처럼 보입니다.

예:

- First list item
- Second list item

- A different list

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  • First list item

  • Second list item

  • A different list

CommonMark는 빈 줄을 무시하고 이를 문단 간격이 적용된 하나의 목록으로 렌더링합니다.

설명 목록#

히스토리
  • 설명 목록이 GitLab 17.7에서 도입되었습니다.

설명 목록은 용어와 그에 대응하는 설명으로 이루어진 목록입니다. 각 용어에는 설명이 여러 개 있을 수 있습니다. HTML에서는 <dl>, <dt>, <dd> 태그로 표현됩니다.

설명 목록을 만들려면 용어를 한 줄에 쓰고, 그다음 줄에 콜론으로 시작하는 설명을 씁니다.

Fruits
: apple
: orange

Vegetables
: broccoli
: kale
: spinach

용어와 설명 사이에 빈 줄을 둘 수도 있습니다.

Fruits

: apple

: orange
Note

리치 텍스트 편집기는 새 설명 목록 삽입을 지원하지 않습니다. 새 설명 목록을 삽입하려면 일반 텍스트 편집기를 사용합니다. 자세한 내용은 이슈 535956을 참고합니다.

작업 목록#

Markdown을 지원하는 모든 위치에 작업 목록을 추가할 수 있습니다.

  • 이슈, 머지 리퀘스트, 에픽, 댓글에서는 체크박스를 선택할 수 있습니다.
  • 그 밖의 모든 위치에서는 체크박스를 선택할 수 없습니다. 대괄호 안에 x를 추가하거나 제거하여 Markdown을 직접 편집해야 합니다.

작업은 완료와 미완료 외에 해당 없음 상태일 수도 있습니다. 이슈, 머지 리퀘스트, 에픽, 댓글에서 해당 없음 체크박스를 선택해도 아무 효과가 없습니다.

작업 목록을 만들려면 순서 있는 목록이나 순서 없는 목록의 형식을 따릅니다.

- [x] Completed task
- [~] Inapplicable task
- [ ] Incomplete task
  - [x] Sub-task 1
  - [~] Sub-task 2
  - [ ] Sub-task 3

1. [x] Completed task
1. [~] Inapplicable task
1. [ ] Incomplete task
   1. [x] Sub-task 1
   1. [~] Sub-task 2
   1. [ ] Sub-task 3

GitLab에서 렌더링된 작업 목록

표 셀에도 작업 목록을 추가할 수 있습니다.

링크#

링크는 여러 방법으로 만들 수 있습니다.

- This line shows an [inline-style link](https://example.com)
- This line shows a [link to a repository file in the same directory](permissions.md)
- This line shows a [relative link to a file one directory higher](../_index.md)
- This line shows a [link that also has title text](https://example.com "This link takes you to Example!")

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

위키 페이지에서 프로젝트 파일을, 또는 프로젝트 파일에서 위키 페이지를 참조하는 데는 상대 링크를 사용할 수 없습니다. GitLab에서 위키는 항상 별도의 Git 리포지터리에 있기 때문에 이러한 제한이 있습니다. 예를 들어 [I'm a reference-style link](style)는 링크가 위키 Markdown 파일 안에 있을 때만 wikis/style을 가리킵니다. 자세한 내용은 위키 전용 Markdown을 참고합니다.

제목 앵커를 사용하여 페이지의 특정 섹션으로 링크합니다.

- This line links to [a section on a different Markdown page, using a `#` and the heading anchor](permissions.md#project-permissions)
- This line links to [a different section on the same page, using a `#` and the heading anchor](#제목-앵커)

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

링크 참조를 사용하는 방법은 다음과 같습니다.

- This line shows a [reference-style link, see below][Arbitrary case-insensitive reference text]
- You can [use numbers for reference-style link definitions, see below][1]
- Or leave it empty and use the [link text itself][], see below.

Some text to show that the reference links can follow later.

[arbitrary case-insensitive reference text]: https://www.mozilla.org/en-US/
[1]: https://slashdot.org
[link text itself]: https://about.gitlab.com/

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Some text to show that the reference links can follow later.

URL 자동 링크#

텍스트에 입력한 거의 모든 URL은 자동으로 링크됩니다.

- https://example.com
- ftp://ftp.us.debian.org/debian/
- smb://foo/bar/baz
- irc://irc.freenode.net/
- http://localhost:3000

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

GitLab 전용 참조#

히스토리
  • 그룹의 레이블을 참조하는 옵션이 GitLab 17.1에서 도입되었습니다.
  • [work_item:123] 구문으로 이슈, 에픽, 작업 항목을 참조하는 옵션:
  • GitLab 18.1에서 extensible_reference_filters라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 18.2에서 정식 출시되었습니다. 기능 플래그 extensible_reference_filters가 제거되었습니다.
  • [epic:123] 구문으로 에픽을 참조하는 옵션이 GitLab 18.4에서 도입되었습니다.
  • 개인 스니펫을 참조하는 기능:
  • GitLab 19.0에서 personal_snippet_reference_filters라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 19.2에서 정식 출시되었습니다. 기능 플래그 personal_snippet_reference_filters가 제거되었습니다.

GitLab Flavored Markdown은 GitLab 전용 참조를 렌더링합니다. 예를 들어 이슈, 커밋, 팀원, 심지어 프로젝트 팀 전체를 참조할 수 있습니다. GitLab Flavored Markdown은 그 참조를 링크로 바꾸므로 서로 이동할 수 있습니다. 프로젝트에 대한 모든 참조는 프로젝트 이름이 아니라 project slug를 사용해야 합니다.

또한 GitLab Flavored Markdown은 특정한 프로젝트 간 참조를 인식하며, 같은 네임스페이스의 다른 프로젝트를 참조하기 위한 단축 표기도 있습니다.

Note

GitLab 전용 참조는 Markdown 스니펫 파일에서 지원되지 않습니다.

GitLab Flavored Markdown은 다음을 인식합니다.

참조 입력 프로젝트 간 참조 같은 네임스페이스 내 단축 표기
특정 사용자 @user_name
특정 그룹 @group_name
팀 전체 @all
프로젝트 namespace/project>
이슈 #123, GL-123, 또는 [issue:123] namespace/project#123 또는 [issue:namespace/project/123] project#123 또는 [issue:project/123]
작업 항목 [work_item:123] [work_item:namespace/project/123] [work_item:project/123]
머지 리퀘스트 !123 namespace/project!123 project!123
스니펫 3 $123 namespace/project$123 project$123
개인 스니펫1 $123
에픽 #123, &123, [work_item:123], 또는 [epic:123] group1/subgroup#123, group1/subgroup&123, [work_item:group1/subgroup/123], 또는 [epic:group1/subgroup/123]
이터레이션 *iteration:"iteration title"
ID로 지정한 이터레이션 케이던스2 [cadence:123]
제목(한 단어)으로 지정한 이터레이션 케이던스2 [cadence:plan]
제목(여러 단어)으로 지정한 이터레이션 케이던스2 [cadence:"plan a"]
취약점 [vulnerability:123] [vulnerability:namespace/project/123] [vulnerability:project/123]
기능 플래그 [feature_flag:123] [feature_flag:namespace/project/123] [feature_flag:project/123]
ID로 지정한 레이블3 ~123 namespace/project~123 project~123
이름(한 단어)으로 지정한 레이블3 ~bug namespace/project~bug project~bug
이름(여러 단어)으로 지정한 레이블3 ~"feature request" namespace/project~"feature request" project~"feature request"
이름(범위 지정)으로 지정한 레이블3 ~"priority::high" namespace/project~"priority::high" project~"priority::high"
ID로 지정한 프로젝트 마일스톤3 %123 namespace/project%123 project%123
이름(한 단어)으로 지정한 마일스톤3 %v1.23 namespace/project%v1.23 project%v1.23
이름(여러 단어)으로 지정한 마일스톤3 %"release candidate" namespace/project%"release candidate" project%"release candidate"
커밋(특정 커밋) 9ba12248 namespace/project@9ba12248 project@9ba12248
커밋 범위 비교 9ba12248...b19a04f5 namespace/project@9ba12248...b19a04f5 project@9ba12248...b19a04f5
리포지터리 파일 참조 [README](doc/README.md)
리포지터리 파일 참조(특정 줄) [README](doc/README.md#L13)
경고 ^alert#123 namespace/project^alert#123 project^alert#123
연락처 [contact:test@example.com]
위키 페이지(페이지 슬러그가 제목과 같은 경우) [[Home]] 또는 [wiki_page:Home] [wiki_page:namespace/project:Home] 또는 [wiki_page:group1/subgroup:Home]
위키 페이지(페이지 슬러그가 제목과 다른 경우) [[How to use GitLab|how-to-use-gitlab]]

예를 들어 #123을 사용하여 이슈를 참조하면 텍스트가 #123인 123번 이슈로의 링크로 출력됩니다. 마찬가지로 123번 이슈로 연결되는 링크도 인식되어 텍스트 #123으로 표시됩니다. #123이 이슈로 링크되는 것을 원하지 않으면 앞에 백슬래시를 붙여 \#123으로 입력합니다.

이와 함께 일부 객체에 대한 링크도 인식되어 서식이 지정됩니다. 예:

  • 이슈의 댓글: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234#note_101075757"은 #1234 (comment 101075757)로 렌더링됩니다.
  • 이슈 디자인 탭: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234/designs"는 #1234 (designs)로 렌더링됩니다.
  • 개별 디자인 링크: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234/designs/layout.png"는 #1234[layout.png]로 렌더링됩니다.

항목 제목 표시#

히스토리
  • 에픽 지원이 GitLab 17.7에서 work_item_epics라는 플래그와 함께 도입되었으며, 기본적으로 활성화되어 있습니다.
  • 에픽에 대해 GitLab 18.1에서 정식 출시되었습니다. 기능 플래그 work_item_epics가 제거되었습니다.

이슈, 태스크, 목표, 핵심 결과, 머지 리퀘스트, 에픽의 렌더링된 링크에 제목을 포함하려면 다음과 같이 합니다.

  • 참조 끝에 더하기 기호(+)를 추가합니다.

예를 들어 #123+ 같은 참조는 The issue title (#123)로 렌더링됩니다.

https://gitlab.com/gitlab-org/gitlab/-/issues/1234+ 같은 URL 참조도 확장됩니다.

항목 요약 표시#

히스토리
  • 에픽 지원이 GitLab 17.7에서 work_item_epics라는 플래그와 함께 도입되었으며, 기본적으로 활성화되어 있습니다.
  • 에픽에 대해 GitLab 18.1에서 정식 출시되었습니다. 기능 플래그 work_item_epics가 제거되었습니다.

에픽, 이슈, 태스크, 목표, 핵심 결과, 머지 리퀘스트의 렌더링된 링크에 확장 요약을 포함하려면 다음과 같이 합니다.

  • 참조 끝에 +s를 추가합니다.

요약에는 참조된 항목의 담당자, 마일스톤, 상태(health status) 정보가 작업 항목 유형에 맞게 포함됩니다.

예를 들어 #123+s 같은 참조는 The issue title (#123) • First Assignee, Second Assignee+ • v15.10 • Needs attention로 렌더링됩니다.

https://gitlab.com/gitlab-org/gitlab/-/issues/1234+s 같은 URL 참조도 확장됩니다.

담당자, 마일스톤 또는 상태가 변경되었을 때 렌더링된 참조를 업데이트하려면 다음과 같이 합니다.

  • 페이지를 새로 고칩니다.

마우스를 올렸을 때의 댓글 미리 보기#

히스토리
  • GitLab 17.3에서 comment_tooltips라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 17.6에서 기능 플래그가 제거되었습니다.

댓글로 연결되는 링크에 마우스를 올리면 작성자와 댓글의 첫 줄이 표시됩니다.

Observability 대시보드 삽입#

에픽, 이슈, MR 등의 설명과 댓글에 GitLab Observability UI 대시보드를 삽입할 수 있습니다.

Observability 대시보드 URL을 삽입하려면 다음과 같이 합니다.

  1. GitLab Observability UI에서 주소 표시줄의 URL을 복사합니다.
  2. 댓글이나 설명에 링크를 붙여넣습니다. GitLab Flavored Markdown이 URL을 인식하여 소스를 표시합니다.

표#

표를 만들 때는 다음을 따릅니다.

  • 첫 번째 줄에는 파이프 문자(|)로 구분된 헤더를 넣습니다.
  • 두 번째 줄은 헤더와 셀을 구분합니다.
    • 셀에는 빈 공백, 하이픈, 그리고 (선택 사항으로) 가로 정렬을 위한 콜론만 넣을 수 있습니다.
    • 각 셀에는 하이픈이 하나 이상 있어야 하며, 셀에 하이픈을 더 넣어도 셀의 렌더링은 달라지지 않습니다.
    • 하이픈, 공백, 콜론 이외의 내용은 허용되지 않습니다.
  • 세 번째 줄과 그 이후의 줄에는 셀 값을 넣습니다.
    • Markdown에서 셀을 여러 줄에 걸쳐 나눌 수 없습니다. 한 줄로 유지해야 하지만 매우 길어도 됩니다. 필요하면 HTML <br> 태그를 넣어 줄 바꿈을 강제할 수도 있습니다.
    • 셀의 크기는 서로 같지 않아도 됩니다. 유연하지만 파이프(|)로 구분해야 합니다.
    • 빈 셀을 둘 수 있습니다.
  • 칼럼 너비는 셀의 내용에 따라 동적으로 계산됩니다.
  • 파이프 문자(|)를 표 구분자가 아니라 텍스트로 사용하려면 백슬래시(\|)로 이스케이프해야 합니다.

예:

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

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

header 1 header 2 header 3
cell 1 cell 2 cell 3
cell 4 cell 5 is longer cell 6 is much longer than the others, but that's ok. It eventually wraps the text when the cell is too large for the display size.
cell 7 cell 9

정렬#

또한 두 번째 줄의 "대시" 줄 양쪽에 콜론(:)을 추가하여 칼럼 안 텍스트의 정렬을 선택할 수 있습니다. 이는 칼럼의 모든 셀에 영향을 줍니다.

| Left Aligned | Centered | Right Aligned |
| :----------- | :------: | ------------: |
| Cell 1       | Cell 2   | Cell 3        |
| Cell 4       | Cell 5   | Cell 6        |

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Left Aligned Centered Right Aligned
Cell 1 Cell 2 Cell 3
Cell 4 Cell 5 Cell 6

GitLab에서 표 헤더는 Chrome과 Firefox에서는 항상 왼쪽 정렬이고, Safari에서는 가운데 정렬입니다. 자세한 내용은 표를 참고합니다.

여러 줄이 있는 셀#

HTML 서식을 사용하여 표의 렌더링을 조정할 수 있습니다. 예를 들어 <br> 태그를 사용하면 셀이 여러 줄을 갖도록 강제할 수 있습니다.

| Name  | Details |
| ----- | ------- |
| Item1 | This text is on one line |
| Item2 | This item has:<br>- Multiple items<br>- That we want listed separately |

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Name Details
Item1 This text is on one line
Item2 This item has:
- Multiple items
- That we want listed separately

표 안의 작업 목록#

히스토리
  • 표 셀 안의 작업 항목을 위한 기본 Markdown 구문이 GitLab 18.9에서 도입되었습니다.

Markdown 표 셀에 작업 항목 체크박스를 추가할 수 있습니다. 체크박스는 셀의 유일한 내용이어야 합니다.

| Complete | Task                    |
| -------- | ----------------------- |
|   [x]    | Refactor the backend    |
|   [ ]    | Refactor the frontend   |
|   [~]    | Inapplicable task       |

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Markdown 표에서 렌더링된 작업 목록.

하나의 셀에 작업 항목을 여러 개 추가하거나 추가 텍스트가 있는 작업 항목을 추가하려면, 셀 안에 Markdown을 넣은 HTML 표를 사용합니다.

<table>
<thead>
<tr><th>header 1</th><th>header 2</th></tr>
</thead>
<tbody>
<tr>
<td>cell 1</td>
<td>cell 2</td>
</tr>
<tr>
<td>cell 3</td>
<td>

- [ ] Task one
- [ ] Task two

</td>
</tr>
</tbody>
</table>

리치 텍스트 편집기에서 표를 만든 다음 작업 목록을 삽입할 수도 있습니다.

스프레드시트에서 복사하여 붙여넣기#

스프레드시트 소프트웨어(예: Microsoft Excel, Google Sheets, Apple Numbers)에서 작업하는 경우, 스프레드시트에서 복사하여 붙여넣으면 GitLab이 Markdown 표를 생성합니다. 예를 들어 다음과 같은 스프레드시트가 있다고 가정합니다.

스프레드시트에서 복사

셀을 선택하여 클립보드에 복사합니다. GitLab Markdown 입력란을 열고 스프레드시트를 붙여넣습니다.

Markdown 표로 붙여넣기

표 정렬#

히스토리
  • GitLab 19.3에서 markdown_sortable_table_columns라는 기능 플래그와 함께 베타로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 19.5에서 일반 공개되었습니다. 기능 플래그 markdown_sortable_table_columns가 제거되었습니다.

렌더링된 표에서는 칼럼의 값을 기준으로 행을 정렬할 수 있습니다.

표를 정렬하려면 다음과 같이 합니다.

  1. 칼럼 헤더에서 Sort ascending([sort-lowest])을 선택합니다.
  2. Sort descending([sort-highest])을 선택합니다.
  3. 행의 원래 순서를 복원하려면 Reset sorting([redo])을 선택합니다.

텍스트와 빈 공간을 포함해 칼럼 헤더 셀의 어느 곳을 선택해도 같은 정렬 동작을 수행할 수 있습니다. 헤더에 있는 링크는 표를 정렬하지 않고 열립니다.

버튼의 아이콘과 툴팁은 다음에 수행할 동작을 보여 줍니다. 툴팁을 보려면 버튼 위에 마우스를 올리거나 키보드 포커스를 버튼으로 이동합니다. 키보드로 정렬하려면 칼럼 헤더 또는 해당 정렬 버튼으로 포커스를 이동하고 Enter 또는 Space를 누릅니다.

정렬 동작은 다음과 같습니다.

  • 값은 알파벳순으로 정렬되며 대소문자를 구분하지 않습니다.
  • 숫자와 날짜는 숫자 값이나 시간순이 아니라 텍스트로 정렬됩니다.
  • 빈 셀은 오름차순과 내림차순 모두에서 항상 표의 맨 아래로 정렬됩니다.

한 번에 하나의 칼럼만 기준으로 정렬할 수 있습니다. 다른 칼럼을 기준으로 정렬하면 이전 정렬이 해제됩니다.

제외 대상은 다음과 같습니다.

JSON 표#

히스토리
  • Markdown 렌더링이 GitLab 17.9에서 도입되었습니다.

JSON 코드 블록으로 표를 렌더링하려면 다음 구문을 사용합니다.

```json:table
{}
```

이 기능을 안내하는 다음 동영상을 시청합니다.

동영상 보기: Demo: JSON Tables in Markdown.

items 속성은 데이터 포인트를 나타내는 객체의 목록입니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ]
}
```

표 레이블을 지정하려면 fields 속성을 사용합니다.

```json:table
{
    "fields" : ["a", "b", "c"],
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ]
}
```

items의 모든 요소가 fields에 대응하는 값을 가질 필요는 없습니다.

```json:table
{
    "fields" : ["a", "b", "c"],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "c": "233"}
    ]
}
```

fields를 명시적으로 지정하지 않으면 레이블은 items의 첫 번째 요소에서 가져옵니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "c": "233"}
    ]
}
```

fields에 사용자 지정 레이블을 지정할 수 있습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA"},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "b": "222", "c": "233"}
    ]
}
```

fields의 개별 요소에 대해 정렬을 활성화할 수 있습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA", "sortable": true},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "b": "222", "c": "233"}
    ]
}
```

filter 속성을 사용하면 사용자 입력에 따라 내용이 동적으로 필터링되는 표를 렌더링할 수 있습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA"},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "b": "222", "c": "233"}
    ],
    "filter" : true
}
```

markdown 속성을 사용하면 항목과 캡션에서 GitLab 참조를 포함한 GitLab Flavored Markdown을 사용할 수 있습니다. 필드는 Markdown을 지원하지 않습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA"},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "**22**", "c": "33"},
      {"a": "#1", "b": "222", "c": "233"}
    ],
    "markdown" : true
}
```

기본적으로 모든 JSON 표에는 Generated with JSON data라는 캡션이 있습니다. caption 속성을 지정하여 이 캡션을 재정의할 수 있습니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ],
    "caption" : "Custom caption"
}
```

JSON이 유효하지 않으면 오류가 발생합니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ],
}
```

멀티미디어#

이미지, 동영상, 오디오를 삽입합니다. Markdown 구문으로 파일을 링크하고, 크기를 설정하고, 인라인으로 표시하는 방식으로 멀티미디어를 추가할 수 있습니다. 서식 옵션으로 제목을 지정하고, 너비와 높이를 지정하고, 렌더링된 출력에서 미디어가 표시되는 방식을 제어할 수 있습니다.

이미지#

히스토리
  • 이미지를 오버레이로 여는 기능이 GitLab 18.6에서 도입되었습니다.
  • 투명도 체커보드 전환 기능이 GitLab 18.10에서 도입되었습니다.

!를 앞에 붙인 인라인 또는 참조 링크를 사용하여 이미지를 삽입합니다. 예:

![GitLab logo](img/markdown_logo_v17_11.png "Title Text")

GitLab logo

이미지 링크에서는 다음과 같이 처리됩니다.

  • 대괄호([ ]) 안의 텍스트가 이미지 대체 텍스트가 됩니다.
  • 이미지 링크 경로 뒤의 큰따옴표 안에 있는 텍스트가 제목 텍스트가 됩니다. 제목 텍스트를 보려면 이미지 위에 마우스를 올립니다.

자세한 내용은 접근성을 갖춘 이미지와 동영상을 참고합니다.

이미지를 선택하면 오버레이로 열립니다.

이미지에 투명한 영역이 있으면 이미지 위에 마우스를 올리고 Toggle transparency checkerboard를 선택하여 체커보드 배경을 표시합니다. 체커보드를 사용하면 어떤 테마에서도 투명한 영역을 볼 수 있습니다. Toggle transparency checkerboard는 픽셀의 5% 이상이 어느 정도 투명한(완전히 불투명하지 않은) PNG, WebP, GIF 이미지에 표시됩니다. 투명한 픽셀이 5% 미만인 이미지에는 이 전환 버튼이 표시되지 않습니다.

동영상#

동영상 확장자를 가진 파일을 링크하는 이미지 태그는 자동으로 동영상 플레이어로 변환됩니다. 유효한 동영상 확장자는 .mp4, .m4v, .mov, .webm, .ogv입니다.

다음은 동영상 예제입니다.

![Sample Video](img/markdown_video.mp4)

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

Sample Video

이미지 또는 동영상 크기 변경#

이미지나 동영상 뒤에 속성 목록을 추가하여 너비와 높이를 제어할 수 있습니다. 값은 단위가 px(기본값) 또는 %인 정수여야 합니다.

예:

![GitLab logo](img/markdown_logo_v17_11.png "Title Text"){width=100 height=100px}

![GitLab logo](img/markdown_logo_v17_11.png "Title Text"){width=75%}

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

GitLab logo{width=100 height=100px}

Markdown 대신 img HTML 태그를 사용하고 height와 width 매개변수를 설정할 수도 있습니다.

GitLab 17.1 이상에서 해상도가 높은 PNG 이미지를 Markdown 텍스트 상자에 붙여넣으면 크기가 항상 함께 추가됩니다. 이 크기는 레티나(및 기타 고해상도) 디스플레이에 맞게 자동으로 조정됩니다. 예를 들어 144ppi 이미지는 원래 크기의 50%로, 96ppi 이미지는 원래 크기의 75%로 조정됩니다.

이미지를 선택하면 100% 또는 창에 맞는 가장 큰 크기 중 하나로 조정되어 오버레이로 열립니다.

오디오#

동영상과 마찬가지로, 오디오 확장자를 가진 파일의 링크 태그는 자동으로 오디오 플레이어로 변환됩니다. 유효한 오디오 확장자는 .mp3, .oga, .ogg, .spx, .wav입니다.

다음은 오디오 클립 예제입니다.

![Sample Audio](img/markdown_audio.mp3)

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

Sample Audio

삽입된 콘텐츠#

히스토리
  • GitLab 18.5에서 allow_iframes_in_markdown라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • 삽입 공급자가 GitLab 19.5에서 도입되었습니다. 삽입 공급자가 도메인 허용 목록을 대체합니다.
Feature flag

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로 사용할 수 있으며, 프로덕션에서 사용할 준비가 되지 않았습니다.

허용된 삽입 공급자의 콘텐츠로 연결되는 이미지 태그는 삽입된 콘텐츠로 렌더링됩니다. 콘텐츠는 샌드박스 프레임에서 로드되며, 로드되는 위치를 보여 주는 레이블이 함께 표시됩니다. 일부 공급자는 콘텐츠가 로드되기 전에 Load external content를 선택해야 합니다. URL이 허용된 공급자와 일치하지 않으면 표준 이미지로 렌더링됩니다.

사용 가능한 삽입 공급자는 GitLab이 정의합니다. 관리자가 허용할 공급자를 선택합니다.

  • Admin 영역의 Settings > General에 있는 Embedded content 섹션에서 선택합니다.
  • 애플리케이션 설정 API의 iframe_rendering_enabled 및 iframe_rendering_allowlist 속성으로 선택합니다.

다음 삽입 공급자를 사용할 수 있습니다.

공급자 ID 허용되는 URL
YouTube youtube https://www.youtube.com/watch?v=<id>, https://youtu.be/<id> 또는 https://www.youtube.com/embed/<id>
Figma figma https://www.figma.com/<type>/<id> 또는 https://embed.figma.com/<type>/<id>. <type>은 proto, design, board, file, slides 중 하나입니다

공급자의 <iframe> 삽입 코드를 붙여넣을 수도 있습니다.

예를 들어 YouTube 공급자가 허용된 경우:

![Demo: JSON Tables in Markdown](https://www.youtube.com/watch?v=12yWKw1AdKY)

인용문#

인용문을 사용하여 참고 사항 같은 정보를 강조합니다. 인용문은 줄을 >로 시작하여 만듭니다.

> Blockquotes help you emulate reply text.
> This line is part of the same quote.

Quote break.

> This very long line is still quoted properly when it wraps. Keep writing to make sure this line is long enough to actually wrap for everyone. You can also *use* **Markdown** in a blockquote.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Blockquotes help you emulate reply text. This line is part of the same quote.

Quote break.

This very long line is still quoted properly when it wraps. Keep writing to make sure this line is long enough to actually wrap for everyone. You can also use Markdown in a blockquote.

여러 줄 인용문#

>>>로 감싸서 여러 줄 인용문을 만듭니다.

>>>
If you paste a message from somewhere else

that spans multiple lines,

you can quote that without having to manually prepend `>` to every line!
>>>

If you paste a message from somewhere else

that spans multiple lines,

you can quote that without having to manually prepend > to every line!

코드 스팬과 코드 블록#

표준 텍스트가 아니라 코드로 보아야 하는 모든 것을 강조합니다.

인라인 코드는 백틱 하나 `로 서식을 지정합니다.

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

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Inline code has back-ticks around it.

더 큰 코드 예제에 비슷한 효과를 내려면 코드 블록을 사용할 수 있습니다. 코드 블록을 만드는 방법은 다음과 같습니다.

  • 코드 블록 전체를 백틱 세 개(```)로 감쌉니다. 여는 쪽과 닫는 쪽의 개수가 같다면 백틱을 세 개보다 많이 사용할 수 있습니다.
  • 코드 블록 전체를 물결표 세 개(~~~)로 감쌉니다.
  • 공백 네 개 이상으로 들여씁니다.

예:

Python code block:

```python
def function():
    #indenting works just fine in the fenced code block
    s = "Python code"
    print(s)
```

Markdown code block using 4 spaces:

    Using 4 spaces
    is like using
    3-backtick fences.

JavaScript code block using tildes:

~~~javascript
const s = "JavaScript syntax highlighting";
alert(s);
~~~

앞의 세 예제는 다음과 같이 렌더링됩니다.

Python code block:

def function():
    #indenting works just fine in the fenced code block
s = "Python code"
print(s)

Markdown code block using 4 spaces:

```plaintext
Using 4 spaces
is like using
3-backtick fences.

JavaScript code block using tildes:

const s = "JavaScript syntax highlighting";
alert(s);

구문 강조#

GitLab은 코드 블록에서 더 다채로운 구문 강조를 위해 Rouge Ruby 라이브러리를 사용합니다. 지원되는 언어 목록은 Rouge 프로젝트 위키를 참고합니다. 구문 강조는 코드 블록에서만 지원되므로 인라인 코드는 강조할 수 없습니다.

코드 블록을 감싸고 구문 강조를 적용하려면 여는 코드 선언에서 백틱 세 개(```) 또는 물결표 세 개(~~~) 뒤에 코드 언어를 덧붙입니다.

plaintext를 사용하거나 코드 언어를 지정하지 않은 코드 블록에는 구문 강조가 적용되지 않습니다.

```
No language indicated, so **no** syntax highlighting.
s = "No highlighting is shown for this line."
But let's throw in a <b>tag</b>.
```

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

No language indicated, so **no** syntax highlighting.
s = "No highlighting is shown for this line."
But let's throw in a <b>tag</b>.

리포지터리의 코드 삽입#

히스토리
  • GitLab 19.4에서 blob_permalink_embed라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 19.5에서 일반 공개되었습니다. 기능 플래그 blob_permalink_embed가 제거되었습니다.

리포지터리에 있는 파일의 특정 줄에 대한 퍼머링크를 붙여넣으면, GitLab은 그 링크를 해당 줄의 구문 강조된 스니펫으로 바꿉니다. 삽입된 코드의 헤더에는 파일 경로와 삽입된 줄이 표시됩니다. 해당 커밋 시점의 파일로 이동하려면 헤더나 줄 번호를 선택합니다.

리포지터리의 코드를 삽입하려면 다음과 같이 합니다.

  1. 파일의 한 줄 또는 여러 줄 범위에 대한 퍼머링크를 만듭니다.
  2. 댓글이나 설명에서 별도의 문단으로 퍼머링크를 붙여넣습니다.

예:

The external URL is configured here:

https://gitlab.com/gitlab-org/gitlab/-/blob/d768310246d88433a5534576776939d81846f19e/config/gitlab.yml.example#L35-37

퍼머링크는 다음 조건을 충족해야 합니다.

  • 같은 GitLab 인스턴스에 있는 프로젝트를 가리켜야 합니다.
  • 40자 전체 커밋 SHA를 포함해야 합니다. 브랜치 이름이나 태그 이름을 사용하는 링크는 삽입되지 않습니다.
  • #L27 또는 #L27-30 같은 줄 또는 줄 범위 앵커로 끝나야 합니다.
  • 해당 문단의 유일한 내용이어야 하며, 링크 텍스트가 URL과 일치해야 합니다. 일반 텍스트로 붙여넣은 퍼머링크는 이 두 조건을 모두 충족합니다.

제한#

GitLab은 다음을 삽입하지 않습니다.

  • 100줄을 초과하는 범위, 또는 5000번째 줄 이후에서 끝나는 범위.
  • 파일의 마지막 줄 이후에서 시작하는 범위.
  • 바이너리 파일, 10MB보다 큰 파일, Git LFS에 저장된 파일.
  • 하나의 Markdown 문서에서 10개를 초과하는 삽입.

범위가 파일의 마지막 줄 이후에서 끝나더라도 GitLab은 이를 삽입하며, 삽입된 코드는 마지막 줄에서 끝납니다.

프로젝트 간 퍼머링크#

다른 프로젝트에 대한 퍼머링크는 해당 프로젝트의 코드를 볼 수 있는 사용자에게만 삽입됩니다. 다른 사용자에게는 퍼머링크가 그대로 표시되므로, 작성자와 댓글의 독자가 서로 같은 내용을 보지 못할 수 있습니다.

이메일 알림#

GitLab은 다음 두 곳 모두에서 diff 미리 보기가 켜져 있을 때만 이메일 알림에 코드를 삽입합니다.

  • 알림이 발생한 프로젝트 또는 그룹.
  • 퍼머링크가 가리키는 프로젝트.

GitLab은 Service Desk 이메일에는 코드를 삽입하지 않습니다. 이러한 경우 이메일에는 퍼머링크가 그대로 표시됩니다. diff 미리 보기는 프로젝트 또는 그룹의 모든 프로젝트에서 끌 수 있습니다.

다이어그램 및 순서도#

다음을 사용하여 텍스트로 다이어그램을 생성할 수 있습니다.

위키에서는 diagrams.net 편집기로 만든 다이어그램도 추가하고 편집할 수 있습니다.

Mermaid#

히스토리
  • treeView-beta 다이어그램 지원이 GitLab 19.4에서 도입되었습니다.

자세한 내용은 공식 페이지를 참고합니다. Mermaid Live Editor는 Mermaid를 배우고 Mermaid 코드의 문제를 디버그하는 데 도움이 됩니다. 이를 사용하여 다이어그램의 문제를 파악하고 해결합니다.

GitLab은 Mermaid 버전 11을 지원합니다.

다이어그램이나 순서도를 생성하려면 mermaid 블록 안에 텍스트를 작성합니다.

<div class="diagram-placeholder"><div class="diagram-placeholder-header">Mermaid 다이어그램 (8줄)</div><details><summary>소스 코드 보기</summary><pre><code>graph TD
    accTitle: Basic Mermaid diagram example
    accDescr: Simple flowchart showing nodes A, B, C, and D with connections between them.

  A--&gt;B;
  A--&gt;C;
  B--&gt;D;
  C--&gt;D;</code></pre></details></div>

Note

GitLab Self-Managed에서 Cross-Origin-Resource-Policy 헤더를 same-site 또는 same-origin으로 구성한 경우 Mermaid 다이어그램이 아무 오류 표시 없이 렌더링에 실패합니다. 이를 해결하려면 대신 cross-origin을 사용합니다. 자세한 내용은 Cross-Origin-Resource-Policy 헤더와 Mermaid 다이어그램을 참고합니다.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Mermaid 다이어그램 (8줄)
소스 코드 보기
graph TD
    accTitle: Basic Mermaid diagram example
    accDescr: Simple flowchart showing nodes A, B, C, and D with connections between them.

A-->B; A-->C; B-->D; C-->D;

서브그래프도 포함할 수 있습니다.

<div class="diagram-placeholder"><div class="diagram-placeholder-header">Mermaid 다이어그램 (17줄)</div><details><summary>소스 코드 보기</summary><pre><code>graph TB
    accTitle: Mermaid diagram with subgraphs
    accDescr: Flowchart showing main graph with two subgraphs containing nodes and decision flows.

  SubGraph1 --&gt; SubGraph1Flow

  subgraph "SubGraph 1 Flow"
    SubGraph1Flow(SubNode 1)
    SubGraph1Flow -- Choice1 --&gt; DoChoice1
    SubGraph1Flow -- Choice2 --&gt; DoChoice2
  end

  subgraph "Main Graph"
    Node1[Node 1] --&gt; Node2[Node 2]
    Node2 --&gt; SubGraph1[Jump to SubGraph1]
    SubGraph1 --&gt; FinalThing[Final Thing]
  end</code></pre></details></div>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Mermaid 다이어그램 (17줄)
소스 코드 보기
graph TB
    accTitle: Mermaid diagram with subgraphs rendered
    accDescr: Flowchart showing main graph with two subgraphs containing nodes and decision flows as rendered.

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

파일 또는 디렉터리 트리를 렌더링하려면 treeView-beta 다이어그램을 사용합니다. 들여쓰기가 계층 구조를 정의하며, 끝의 /는 디렉터리를 나타냅니다.

<div class="diagram-placeholder"><div class="diagram-placeholder-header">Mermaid 다이어그램 (8줄)</div><details><summary>소스 코드 보기</summary><pre><code>treeView-beta
    accTitle: Mermaid file tree diagram
    accDescr: A file tree with a project directory containing a src directory, index.js, package.json, and a README file.
    my-project/
        src/
            index.js
        package.json
        README.md</code></pre></details></div>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Mermaid 다이어그램 (8줄)
소스 코드 보기
treeView-beta
    accTitle: Mermaid file tree diagram
    accDescr: A file tree with a project directory containing a src directory, index.js, package.json, and a README file.
    my-project/
        src/
            index.js
        package.json
        README.md

PlantUML#

PlantUML 통합은 GitLab.com에서 활성화되어 있습니다. GitLab Self-Managed 설치에서 PlantUML을 사용하려면 GitLab 관리자가 활성화해야 합니다.

PlantUML을 활성화한 후에는 다이어그램 구분자 @startuml/@enduml이 필요하지 않습니다. 이 구분자는 plantuml 블록으로 대체되기 때문입니다. 예:

<div class="diagram-placeholder"><div class="diagram-placeholder-header">PlantUML 다이어그램 (2줄)</div><details><summary>소스 코드 보기</summary><pre><code>Bob -&gt; Alice : hello
Alice -&gt; Bob : hi</code></pre></details></div>

::include 지시문을 사용하여 리포지터리의 별도 파일에서 PlantUML 다이어그램을 포함하거나 삽입할 수 있습니다. 자세한 내용은 다이어그램 파일 포함을 참고합니다.

Kroki#

GitLab에서 Kroki를 사용하려면 GitLab 관리자가 활성화해야 합니다. 자세한 내용은 Kroki 통합 페이지를 참고합니다.

수식#

LaTeX 구문으로 작성한 수식은 KaTeX로 렌더링됩니다. KaTeX는 LaTeX의 일부만 지원합니다. 이 구문은 AsciiDoc 위키와 :stem: latexmath를 사용하는 파일에서도 동작합니다. 자세한 내용은 Asciidoctor 사용자 매뉴얼을 참고합니다.

악의적인 활동을 방지하기 위해 GitLab은 처음 1000개의 인라인 수식 인스턴스만 렌더링합니다. 그룹 또는 전체 GitLab Self-Managed 인스턴스에 대해 이 제한을 비활성화할 수 있습니다.

수식 블록의 수도 렌더링 시간에 따라 제한됩니다. 제한을 초과하면 GitLab은 초과한 수식 인스턴스를 텍스트로 렌더링합니다. 위키와 리포지터리 파일에는 이러한 제한이 없습니다.

백틱을 사용한 달러 기호($`...`$) 또는 달러 기호 하나($...$) 사이에 작성한 수식은 텍스트와 같은 줄에 인라인으로 렌더링됩니다.

달러 기호 두 개($$...$$) 사이에 작성하거나 언어를 math로 선언한 코드 블록에 작성한 수식은 별도의 줄에 렌더링됩니다.

This math is inline: $`a^2+b^2=c^2`$.

This math is on a separate line using a ` ```math ` block:

```math
a^2+b^2=c^2
```

This math is on a separate line using inline `$$`: $$a^2+b^2=c^2$$

This math is on a separate line using a `$$...$$` block:

$$
a^2+b^2=c^2
$$

렌더링하면 예제는 다음과 같이 표시됩니다.

GitLab의 수식 예시

Note

리치 텍스트 편집기는 새 수식 블록 삽입을 지원하지 않습니다. 새 수식 블록을 삽입하려면 일반 텍스트 편집기를 사용합니다. 자세한 내용은 이슈 366527을 참고합니다.

목차#

목차는 문서의 하위 제목으로 연결되는 순서 없는 목록입니다. 이슈, 머지 리퀘스트, 에픽에는 목차를 추가할 수 있지만 노트나 댓글에는 추가할 수 없습니다.

지원되는 콘텐츠 유형의 description 필드에 다음 태그 중 하나를 독립된 줄로 추가합니다.

[[_TOC_]]
or
[TOC]
  • Markdown 파일.
  • 위키 페이지.
  • 이슈.
  • 머지 리퀘스트.
  • 에픽.
Note

대괄호 하나로 감싼 TOC 코드를 사용하면 독립된 줄에 있는지와 관계없이 목차가 렌더링됩니다. 이 동작은 의도된 것이 아닙니다. 자세한 내용은 이슈 359077을 참고합니다.

This is an intro sentence to my wiki page.

[[_TOC_]]

## My first heading

First section content.

## My second heading

Second section content.

위키에서 자동 생성된 목차의 미리 보기

알림#

히스토리
  • GitLab 17.10에서 도입되었습니다.

알림은 무언가를 강조하거나 주의를 환기하는 데 사용할 수 있습니다. 알림 구문은 Markdown 인용문 구문 뒤에 알림 유형을 붙여 사용합니다. Markdown을 지원하는 모든 텍스트 상자에서 알림을 사용할 수 있습니다.

다음 유형의 알림을 사용할 수 있습니다.

  • Note: 훑어보는 경우에도 사용자가 고려해야 하는 정보:

    > [!note]
    > The following information is useful.
    
  • Tip: 사용자가 더 성공적으로 작업하도록 돕는 선택적 정보:

    > [!tip]
    > Tip of the day.
    
  • Important: 사용자가 성공하는 데 필수적인 핵심 정보:

    > [!important]
    > This is something important you should know.
    
  • Caution: 어떤 작업으로 인해 발생할 수 있는 부정적인 결과:

    > [!caution]
    > You need to be very careful about the following.
    
  • Warning: 심각한 잠재적 위험:

    > [!warning]
    > The following would be dangerous.
    

알림에 표시되는 제목 텍스트는 기본적으로 알림의 이름입니다. 예를 들어 > [!warning] 알림의 제목은 Warning입니다.

알림 블록의 제목을 바꾸려면 같은 줄에 원하는 텍스트를 입력합니다. 예를 들어 경고 색상을 사용하되 제목을 Data deletion으로 하려면 다음과 같이 합니다.

> [!warning] Data deletion
> The following instructions will make your data unrecoverable.

여러 줄 인용문도 알림 구문을 지원합니다. 이를 사용하면 길고 복잡한 텍스트를 알림으로 감쌀 수 있습니다.

>>> [!note] Things to consider
You should consider the following ramifications:

1. consideration 1
1. consideration 2
>>>

알림은 다음과 같이 렌더링됩니다.

GitLab에서 Markdown 알림이 렌더링되는 모습

색상#

Markdown은 텍스트 색상 변경을 지원하지 않습니다.

색상 코드는 HEX, RGB, HSL 형식으로 작성할 수 있습니다.

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

이름으로 지정하는 색상은 지원되지 않습니다.

GitLab 애플리케이션에서는(GitLab 문서에서는 제외) 백틱으로 감싼 색상 코드 옆에 색상 칩이 표시됩니다. 예:

- `#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)`

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

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

색상 코드 이스케이프#

히스토리
  • GitLab 18.3에서 도입되었습니다.

색상 칩을 생성하지 않고 색상 코드를 인라인 코드로 표시하려면 앞에 백슬래시(\)를 붙입니다.

예:

  • \#FF0000
  • \RGB(255,0,0)
  • \HSL(0,100%,50%)

모든 경우에 백슬래시는 제거되며 출력에는 색상 칩이 렌더링되지 않습니다.

이슈 번호 같은 값을 의도치 않게 색상 칩이 생기지 않도록 인라인 코드에 포함하려는 경우에 사용합니다.

이모지#

GitLab Flavored Markdown을 지원하는 모든 위치에서 이모지를 사용할 수 있습니다. 예:

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

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 :heart: you for that.

If you're new to this, don't be :fearful:. You can join the emoji :family:.
Just look up one of the supported codes.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

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

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

If you're new to this, don't be :fearful:. You can join the emoji :family:. Just look up one of the supported codes.

지원되는 모든 이모지 코드 목록은 이모지 치트 시트를 참고합니다.

이모지와 운영 체제#

앞의 이모지 예제는 하드코딩된 이미지를 사용합니다. GitLab에서 렌더링되는 이모지는 사용하는 OS와 브라우저에 따라 다르게 보일 수 있습니다.

대부분의 이모지는 macOS, Windows, iOS, Android에서 기본적으로 지원되며, 지원되지 않는 환경에서는 이미지 기반 이모지로 대체됩니다.

Linux에서는 Noto Color Emoji를 다운로드하면 이모지를 기본으로 완전히 지원할 수 있습니다. Ubuntu 22.04는(최신 Linux 배포판 대부분과 마찬가지로) 이 글꼴이 기본으로 설치되어 있습니다.

사용자 지정 이모지 추가에 대한 자세한 내용은 사용자 지정 이모지를 참고합니다.

프런트 매터#

프런트 매터는 Markdown 문서의 맨 앞, 내용보다 앞에 포함되는 메타데이터입니다. 이 데이터는 Jekyll, Hugo 같은 정적 사이트 생성기와 그 밖의 많은 애플리케이션에서 사용할 수 있습니다.

GitLab이 렌더링한 Markdown 파일을 볼 때 프런트 매터는 문서 맨 위의 상자 안에 있는 그대로 표시됩니다. HTML 콘텐츠는 프런트 매터 뒤에 표시됩니다. 예시를 보려면 GitLab 문서 파일에서 원본 보기와 렌더링 보기를 전환해 볼 수 있습니다.

GitLab에서 프런트 매터는 Markdown 파일과 위키 페이지에서만 사용되며, Markdown 서식을 지원하는 다른 위치에서는 사용되지 않습니다. 프런트 매터는 문서의 맨 위에 있어야 하며 구분자 사이에 있어야 합니다.

다음 구분자가 지원됩니다.

  • YAML(---):

    ---
    title: About Front Matter
    example:
      language: yaml
    ---
    
  • TOML(+++):

    +++
    title = "About Front Matter"
    [example]
    language = "toml"
    +++
    
  • JSON(;;;):

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

기존 구분자에 지정자를 추가하면 다른 언어도 지원됩니다. 예:

---php
$title = "About Front Matter";
$example = array(
  'language' => "php",
);
---

포함#

히스토리
  • GitLab 17.7에서 도입되었습니다.

포함(include) 또는 포함 지시문을 사용하면 한 문서의 내용을 다른 문서 안에 추가할 수 있습니다.

예를 들어 책을 여러 장으로 나눈 다음, 각 장을 메인 책 문서에 포함할 수 있습니다.

::include{file=chapter1.md}

::include{file=chapter2.md}

GitLab에서 포함 지시문은 Markdown 파일과 위키 페이지에서만 사용되며, Markdown 서식을 지원하는 다른 위치에서는 사용되지 않습니다.

Markdown 파일에서 포함 지시문을 사용하는 방법은 다음과 같습니다.

::include{file=example_file.md}

위키 페이지에서 포함 지시문을 사용하는 방법은 다음과 같습니다.

::include{file=example_page.md}

각 ::include는 줄의 시작에서 시작해야 하며, file=에 파일 또는 URL을 지정합니다. 지정한 파일(또는 URL)의 내용은 ::include의 위치에 포함되고 나머지 Markdown과 함께 처리됩니다.

포함된 파일 안의 포함 지시문은 무시됩니다. 예를 들어 file1이 file2를 포함하고 file2가 file3을 포함하는 경우, file1을 처리할 때 file3의 내용은 포함되지 않습니다.

포함 제한#

좋은 시스템 성능을 보장하고 악의적인 문서가 문제를 일으키는 것을 방지하기 위해 GitLab은 문서에서 처리하는 포함 지시문의 수에 최대 제한을 둡니다. 기본적으로 문서에는 포함 지시문을 최대 32개까지 둘 수 있습니다.

처리되는 포함 지시문의 수를 조정하려면 관리자가 애플리케이션 설정 API로 asciidoc_max_includes 애플리케이션 설정을 변경할 수 있습니다.

외부 URL의 포함 사용#

별도의 위키 페이지나 외부 URL의 포함을 사용하려면 관리자가 wiki_asciidoc_allow_uri_includes 애플리케이션 설정을 활성화할 수 있습니다.

<!-- define application setting wiki_asciidoc_allow_uri_includes to true to allow content to be read from URI -->
::include{file=https://example.org/installation.md}

코드 블록에서 포함 사용#

코드 블록 안에서 ::include 지시문을 사용하여 리포지터리의 파일에 있는 내용을 추가할 수 있습니다. 예를 들어 리포지터리에 javascript_code.js 파일이 있다고 가정합니다.

const s = "JavaScript syntax highlighting";
alert(s);

이를 Markdown 파일에 포함할 수 있습니다.

Our script contains:

```javascript
::include{file=javascript_code.js}
```

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Our script contains:

const s = "JavaScript syntax highlighting";
alert(s);

플레이스홀더#

히스토리
Feature flag

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로 사용할 수 있으며, 프로덕션에서 사용할 준비가 되지 않았습니다.

플레이스홀더를 사용하면 프로젝트의 제목이나 최신 태그처럼 변경될 수 있는 특정 유형의 데이터를 표시할 수 있습니다. 플레이스홀더는 Markdown이 렌더링될 때마다 채워집니다.

구문은 %{PLACEHOLDER}입니다.

플레이스홀더 예시 값 설명
%{gitlab_server} gitlab.com 프로젝트의 서버
%{gitlab_pages_domain} pages.gitlab.com GitLab Pages를 호스팅하는 도메인
%{project_path} gitlab-org/gitlab 상위 그룹을 포함한 프로젝트의 경로
%{project_name} gitlab 프로젝트의 이름
%{project_id} 278964 프로젝트와 연결된 데이터베이스 ID
%{project_namespace} gitlab-org 프로젝트의 프로젝트 네임스페이스
%{project_title} GitLab 프로젝트의 제목
%{group_name} gitlab-org 프로젝트가 속한 그룹
%{default_branch} main 프로젝트 리포지터리에 구성된 기본 브랜치 이름
%{current_ref} feature-branch 현재 보고 있는 ref(브랜치, 태그 또는 커밋 SHA)
%{commit_sha} ad10e011ce65492322037633ebc054efde37b143 프로젝트 리포지터리의 기본 브랜치에 대한 가장 최근 커밋의 ID
%{latest_tag} v17.10.7-ee 프로젝트 리포지터리에 추가된 최신 태그
%{merge_request_iid} 57 머지 리퀘스트 URL의 프로젝트 수준 IID. 머지 리퀘스트를 생성한 후에만 사용할 수 있습니다.

이스케이프 문자#

Markdown은 페이지 서식을 지정하기 위해 다음 ASCII 문자를 예약해 두었습니다.

! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

텍스트에서 이러한 예약 문자 중 하나를 사용하려면 예약 문자 바로 앞에 백슬래시 문자(\)를 추가합니다. 예약 문자 앞에 백슬래시를 두면 Markdown 파서는 백슬래시를 생략하고 예약 문자를 일반 텍스트로 처리합니다.

예:

\# Not a heading

| Food  | Do you like this food? (circle) |
|-------|---------------------------------|
| Pizza | Yes \| No                       |

\**Not bold, just italic text placed between some asterisks*\*

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

# Not a heading

Food Do you like this food? (circle)
Pizza Yes | No

*Not bold, just italic text placed between some asterisks*

백슬래시가 항상 뒤따르는 문자를 이스케이프하는 것은 아닙니다. 다음 경우에는 백슬래시가 일반 텍스트로 표시됩니다.

  • 백슬래시가 A, 3, 공백처럼 예약되지 않은 문자 앞에 있는 경우.
  • 백슬래시가 다음 Markdown 요소 안에 있는 경우.
    • 자동 링크
    • <kbd> 같은 인라인 HTML
    • 코드 블록
    • 코드 스팬

이러한 경우에는 ]에 대한 &#93;처럼 그에 해당하는 HTML 엔티티를 사용해야 할 수 있습니다.

백틱 추가 사용#

앞의 안내는 리터럴 내용이 항상 그대로 표시되는 코드 블록이나 코드 스팬에는 적용되지 않습니다. 대신 백틱을 추가로 사용하여 코드를 중첩합니다.

코드 블록에 백틱 세 개를 포함해야 한다면, 코드 블록을 만들 때 더 많은 개수의 백틱을 사용합니다.

To create a code block in Markdown, use three or more matching backticks:

````markdown
```
code
```
````

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

To create a code block in Markdown, use three or more matching backticks:

```
code
```

코드 스팬에 백틱을 하나 이상 포함하려면 코드 스팬을 만들 때 더 많은 개수의 짝이 맞는 백틱을 사용합니다. 내용이 공백으로 시작하고 끝나면 그 공백도 제거됩니다.

To create a code span in Markdown, use matching backticks: `` `hello, world` ``

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

To create a code span in Markdown, use matching backticks: `hello, world`

백틱과 백슬래시 함께 사용#

백슬래시(\) 문자가 인라인 코드 샘플의 끝에 있으면 백슬래시가 마지막 백틱을 이스케이프할 수 있습니다. 이 경우 인라인 코드 주위에 공백을 추가합니다. 예:

Use the backslash ` \ ` character to escape inline code that ends in a ` backslash\ `.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Use the backslash \ character to escape inline code that ends in a backslash\.

각주#

각주는 Markdown 파일의 끝에 렌더링되는 주석으로 연결되는 링크를 추가합니다.

각주를 만들려면 참조 태그와, (파일의 어느 위치든) 주석 내용이 있는 별도의 줄이 모두 필요합니다.

태그 이름과 관계없이 참조 태그의 상대적인 순서가 렌더링되는 번호를 결정합니다.

주석을 어디에 두든 항상 렌더링된 파일의 맨 아래에 표시됩니다.

Note

리치 텍스트 편집기는 새 각주 삽입을 지원하지 않습니다. 새 각주를 삽입하려면 일반 텍스트 편집기를 사용합니다. 자세한 내용은 이슈 365265를 참고합니다.

예:

  • 각주 참조:

    A footnote reference tag looks like this:[^1]
    
    This reference tag is a mix of letters and numbers. [^footnote-42]
    
  • 파일의 다른 부분에서 각주 정의:

    [^1]: This text is inside a footnote.
    [^footnote-42]: This text is another footnote.
    

렌더링하면 각주는 다음과 비슷하게 표시됩니다.

A footnote reference tag looks like this:4

This reference tag is a mix of letters and numbers.5

인라인 HTML#

Markdown에서 원시 HTML도 사용할 수 있으며, 대개 꽤 잘 동작합니다.

허용되는 HTML 태그와 속성 목록은 HTML::Pipeline의 SanitizationFilter 클래스 문서를 참고합니다. 기본 SanitizationFilter 허용 목록 외에도 GitLab은 span, abbr, details, summary 요소를 허용합니다. Rel-License 마이크로포맷과 라이선스 표기를 지원하기 위해 링크에는 rel="license"가 허용됩니다.

<dl>
  <dt>Definition list</dt>
  <dd>Is something people use sometimes.</dd>

  <dt>Markdown in HTML</dt>
  <dd>Does *not* work **very** well. HTML <em>tags</em> do <b>work</b>, in most cases.</dd>
</dl>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. HTML tags do work, in most cases.

HTML 태그 안에서도 Markdown을 사용할 수 있지만, Markdown이 들어 있는 줄을 별도의 줄로 분리한 경우에만 가능합니다.

<dl>
  <dt>Markdown in HTML</dt>
  <dd>

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

  </dd>
</dl>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Markdown in HTML

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

접을 수 있는 섹션#

HTML의 <details> 및 <summary> 태그를 사용하여 콘텐츠를 접을 수 있습니다. 예를 들어 긴 로그 파일을 접어 화면을 덜 차지하게 합니다.

<details>
<summary>Click to expand</summary>

These details <em>remain</em> <strong>hidden</strong> until expanded.

<pre><code>PASTE LOGS HERE</code></pre>

</details>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Click to expand

These details remain hidden until expanded.

PASTE LOGS HERE

이 태그 안의 Markdown도 지원됩니다.

예제와 같이 모든 Markdown 섹션의 앞뒤에 빈 줄을 남겨 두어야 합니다.

<details>
<summary>

Click to _expand._

</summary>

These details _remain_ **hidden** until expanded.

```
PASTE LOGS HERE
```

</details>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Click to expand.

These details remain hidden until expanded.

PASTE LOGS HERE

키보드 HTML 태그#

<kbd> 요소는 사용자의 키보드 입력을 나타내는 텍스트를 식별하는 데 사용됩니다. <kbd> 태그로 감싼 텍스트는 일반적으로 브라우저의 기본 고정폭 글꼴로 표시됩니다.

Press <kbd>Enter</kbd> to go to the next page.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Press Enter to go to the next page.

위 첨자와 아래 첨자#

GitLab Flavored Markdown은 Redcarpet의 위 첨자 구문( x^2 )을 지원하지 않습니다. 위 첨자와 아래 첨자에는 표준 HTML 구문을 사용합니다.

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

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

The formula for water is H2O while the equation for the theory of relativity is E = mc2.

GitLab Flavored Markdown은 Redcarpet의 위 첨자 구문( x^2 )을 지원하지 않습니다.

HTML 주석#

GitLab Flavored Markdown에서 HTML 주석을 사용하면 렌더링된 출력에는 보이지 않는 메모나 설명을 추가할 수 있습니다.

HTML 주석은 다음 용도로 사용합니다.

  • 다른 기여자를 위한 메모를 추가합니다.
  • 콘텐츠를 삭제하지 않고 임시로 숨깁니다.
  • 최종 문서에 표시되지 않아야 하는 맥락이나 설명을 제공합니다.
  • 메타데이터나 처리 지침을 추가합니다.

HTML 주석을 사용할 때는 다음을 따르는 것이 좋습니다.

  • 소스가 어수선해지지 않도록 필요한 만큼만 사용합니다.
  • 간결하고 관련성 있게 작성합니다.
  • 영구적인 문서화가 아니라 임시 메모에 사용합니다.
  • 민감하거나 기밀인 정보를 포함하지 않습니다. HTML 주석은 Markdown 소스를 볼 수 있는 누구에게나 보입니다.

HTML 주석은 표준 HTML 구문 <!-- comment text -->을 사용하며 한 줄 또는 여러 줄로 작성할 수 있습니다.

<!-- This is a single-line comment -->

<!--
This is a multi-line comment
that spans several lines
and won't be visible in the rendered output
-->

This text is visible.
<!-- This comment between paragraphs is hidden -->
This text is also visible.

렌더링하면 보이는 텍스트만 표시됩니다.

This text is visible.

This text is also visible.

코드 블록 안의 주석#

코드 블록 안의 HTML 주석은 리터럴 텍스트로 처리되어 그대로 표시됩니다.

```html
<!-- This comment will be visible in the code block -->
<div>Content</div>

```

Footnotes

  1. 스니펫 ID는 개인 스니펫과 프로젝트 스니펫 전체에서 고유하므로, 특정 ID는 항상 하나의 스니펫만 식별합니다. ↩

  2. 이터레이션 케이던스 참조는 항상 [cadence:] 형식으로 렌더링됩니다. 예를 들어 참조된 이터레이션 케이던스의 ID가 1이면 텍스트 참조 [cadence:"plan"]은 [cadence:1]로 렌더링됩니다. ↩ ↩2 ↩3

  3. 레이블이나 마일스톤의 경우 namespace/project 앞에 /를 붙여 정확한 레이블 또는 마일스톤을 지정하면, 발생할 수 있는 모호함이 없어집니다. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  4. This text is inside a footnote. ↩

  5. This text is another footnote. ↩

GitLab Flavored Markdown (GLFM)

GitLab v19.5
Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기

요약

GitLab Flavored Markdown(GLFM)은 GitLab 사용자 인터페이스에서 텍스트 서식을 지정하는 마크업 언어입니다. GitLab UI에 텍스트를 입력하면 GitLab은 해당 텍스트가 GitLab Flavored Markdown이라고 가정합니다.

GitLab Flavored Markdown(GLFM)은 GitLab 사용자 인터페이스에서 텍스트 서식을 지정하는 마크업 언어입니다. GLFM은 다음을 제공합니다.

  • 코드, 다이어그램, 수식, 멀티미디어를 지원하여 풍부한 콘텐츠를 만듭니다.
  • 상호 참조로 이슈, 머지 리퀘스트 등 GitLab 콘텐츠를 연결합니다.
  • 작업 목록, 표, 접을 수 있는 섹션으로 정보를 구성합니다.
  • 100개가 넘는 프로그래밍 언어의 구문 강조를 지원합니다.
  • 의미 있는 제목 구조와 이미지 설명으로 접근성을 확보합니다.

GitLab UI에 텍스트를 입력하면 GitLab은 해당 텍스트가 GitLab Flavored Markdown이라고 가정합니다.

GitLab Flavored Markdown은 다음 위치에서 사용할 수 있습니다.

  • 댓글
  • 이슈
  • 에픽
  • 머지 리퀘스트
  • 마일스톤
  • 스니펫(스니펫 이름에 .md 확장자가 있어야 합니다)
  • 위키 페이지
  • 리포지터리 안의 Markdown 문서
  • 릴리스

GitLab에서는 다른 서식 있는 텍스트 파일도 사용할 수 있습니다. 이를 위해 의존성을 설치해야 할 수 있습니다. 자세한 내용은 gitlab-markup gem 프로젝트를 참고합니다.

Note

이 Markdown 사양은 GitLab에서만 유효합니다. 여기에서도 Markdown을 최대한 충실하게 렌더링하지만, GitLab 문서 웹사이트와 GitLab 핸드북은 다른 Markdown 렌더러를 사용합니다.

이 예제들을 GitLab이 정확히 어떻게 렌더링하는지 확인하려면 다음과 같이 합니다.

  1. 해당 원본 Markdown 예제를 복사합니다(렌더링된 예제가 아닙니다).
  2. Markdown 미리 보기를 지원하는 GitLab의 임의 위치(예: 이슈나 머지 리퀘스트의 댓글 또는 설명, 새 Markdown 파일)에 Markdown을 붙여넣습니다.
  3. Preview를 선택하여 GitLab이 렌더링한 Markdown을 확인합니다.

표준 Markdown과의 차이#

GitLab Flavored Markdown은 다음으로 구성됩니다.

모든 표준 Markdown 서식은 GitLab에서 예상대로 동작합니다. 일부 표준 기능은 표준 사용 방식에 영향을 주지 않으면서 추가 기능으로 확장되어 있습니다.

다음 기능은 표준 Markdown에 없습니다.

다음 기능은 표준 Markdown에서 확장되었습니다.

Markdown과 접근성#

GitLab Flavored Markdown을 사용하면 디지털 콘텐츠를 만들게 됩니다. 이 콘텐츠는 독자가 최대한 접근할 수 있어야 합니다. 다음 목록이 전부는 아니지만, 특히 주의해야 할 GitLab Flavored Markdown 스타일에 대한 지침을 제공합니다.

접근성을 갖춘 제목#

제목 서식을 사용하여 논리적인 제목 구조를 만듭니다. 페이지의 제목 구조는 잘 만든 목차처럼 이해가 되어야 합니다. 페이지에 h1 요소가 하나만 있고, 제목 수준을 건너뛰지 않으며, 올바르게 중첩되도록 합니다.

접근성을 갖춘 표#

표를 접근하기 쉽고 훑어보기 쉽게 유지하려면 표에 빈 셀이 없어야 합니다. 셀에 넣을 의미 있는 값이 없다면 "N/A" 또는 "None"을 입력하는 것을 고려합니다.

접근성을 갖춘 이미지와 동영상#

[alt text]에 이미지나 동영상을 설명합니다. 설명은 정확하고, 간결하며, 고유해야 합니다. 설명에 image of 또는 video of를 쓰지 않습니다. 자세한 내용은 WebAim 대체 텍스트를 참고합니다.

작업 항목 및 머지 리퀘스트 제목#

히스토리
  • GitLab Flavored Markdown 전체 지원이 GitLab 18.0에서 도입되었습니다.
  • GitLab Flavored Markdown 전체 지원이 GitLab 18.11에서 제거되었습니다.

이슈, 머지 리퀘스트, 에픽 및 기타 작업 항목의 제목은 GitLab Flavored Markdown을 전체 지원하지 않습니다. 제목에서 지원하는 것은 다음뿐입니다.

  • 코드 스팬(`code`). 백틱 추가 사용이나 이스케이프는 지원되지 않습니다.
  • 이모지(:emoji: 단축 코드와 사용자 지정 이모지).
  • 자동 링크되는 URL.
  • #123, @user, !456 같은 GitLab 전용 참조.

굵게, 기울임, 링크, 제목, 목록 등 표준 Markdown 구문과 그 밖의 블록 수준 서식은 제목에서 처리되지 않습니다. 예를 들어 제목 **Merge request title**은 굵게 표시되지 않고 별표가 그대로 표시됩니다.

제목#

#을 사용하여 1부터 6까지의 제목을 만듭니다.

# H1
## H2
### H3
#### H4
##### H5
###### H6

또는 H1과 H2는 밑줄 스타일을 사용할 수 있습니다.

Alt-H1
======

Alt-H2
------

제목 앵커#

히스토리
  • 제목 링크 생성 방식이 GitLab 17.0에서 변경되었습니다.

GitLab은 모든 Markdown 제목에 앵커를 자동으로 추가하므로 해당 제목으로 링크할 수 있습니다.

마우스를 올리면 해당 앵커로 연결되는 링크가 표시되어, 제목 링크를 복사해 다른 곳에서 사용하기 쉽습니다.

앵커는 다음 규칙에 따라 제목 내용에서 생성됩니다.

  1. 모든 텍스트를 소문자로 변환합니다.
  2. 문자, 숫자, 하이픈, 밑줄을 제외한 모든 문자를 제거합니다.
  3. 모든 공백을 하이픈으로 변환합니다.
  4. 같은 앵커의 제목이 이미 생성되었다면, 1부터 시작하는 고유한 증가 번호를 덧붙입니다.

예:

# This heading has spaces in it
## This heading has a :thumbsup: in it
# This heading has Unicode in it: 한글
## This heading has spaces in it
### This heading has spaces in it
## This heading has 3.5 in it (and parentheses)
## This heading has  multiple spaces and --- hyphens_and_underscores

이 예제는 다음 제목 앵커를 생성합니다.

  1. #this-heading-has-spaces-in-it
  2. #this-heading-has-a-thumbsup-in-it
  3. #this-heading-has-unicode-in-it-한글
  4. #this-heading-has-spaces-in-it-1
  5. #this-heading-has-spaces-in-it-2
  6. #this-heading-has-35-in-it-and-parentheses
  7. #this-heading-has--multiple-spaces-and-----hyphens_and_underscores

스니펫에서는 여러 파일 사이에서 앵커가 충돌하지 않도록 제목에 파일 이름에서 유래한 접두사도 붙습니다. 예를 들어 README.md 파일의 ## TL;DR 제목은 #tldr이 아니라 #readme-tldr 앵커를 갖습니다.

줄 바꿈#

앞의 텍스트가 개행 두 번으로 끝나면 줄 바꿈이 삽입됩니다(새 문단이 시작됩니다). 예를 들어 Enter를 연속으로 두 번 누른 경우입니다. 개행을 한 번만(Enter를 한 번만 눌러) 사용하면 다음 문장은 같은 문단에 속한 상태로 남습니다. 긴 줄이 줄 바꿈되지 않게 하면서 편집하기 쉽게 유지하려면 이 방식을 사용합니다.

Here's a line for us to start with.

This longer line is separated from the one above by two newlines, so it is a *separate paragraph*.

This line is also a separate paragraph, but...
These lines are only separated by single newlines,
so they *do not break* and just follow the previous lines
in the *same paragraph*.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Here's a line for us to start with.

This longer line is separated from the one above by two newlines, so it is a separate paragraph.

This line is also a separate paragraph, but... These lines are only separated by single newlines, so they do not break and just follow the previous lines in the same paragraph.

개행#

문단은 줄 바꿈에서 설명한 대로, 하나 이상의 빈 줄(첫 문단 끝의 개행 두 번)로 구분된 하나 이상의 연속된 텍스트 줄입니다.

줄 바꿈이나 소프트 리턴을 더 세밀하게 제어해야 하는 경우, 줄 끝에 백슬래시나 공백 두 개 이상을 넣으면 줄 바꿈이 하나 추가됩니다. 개행이 연속으로 두 번 있으면 사이에 빈 줄이 있는 새 문단이 만들어집니다.

First paragraph.
Another line in the same paragraph.
A third line in the same paragraph, but this time ending with two spaces.<space><space>
A new line directly under the first paragraph.

Second paragraph.
Another line, this time ending with a backslash.\
A new line due to the previous backslash.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

First paragraph. Another line in the same paragraph. A third line in the same paragraph, but this time ending with two spaces.
A new line directly under the first paragraph.

Second paragraph. Another line, this time ending with a backslash.
A new line due to the previous backslash.

이 구문은 문단과 줄 바꿈 처리에 관한 Markdown 사양을 따릅니다.

강조#

텍스트는 여러 방법으로 강조할 수 있습니다. 기울임, 굵게, 취소선을 사용하거나 이러한 강조 스타일을 함께 조합합니다.

예:

Emphasis, or italics, with *asterisks* or _underscores_.

Strong emphasis, or bold, with double **asterisks** or __underscores__.

Combined emphasis with **asterisks and _underscores_**.

Strikethrough with double tildes. ~~Scratch this.~~

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Emphasis, or italics, with asterisks or underscores.

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

Combined emphasis with asterisks and underscores.

Strikethrough with double tildes. Scratch this.

단어 중간의 강조#

단어의 일부만 기울임 처리하는 것은 피합니다. 특히 밑줄이 여러 개 자주 나오는 코드와 이름을 다룰 때 그렇습니다.

GitLab Flavored Markdown은 코드를 다루는 Markdown 문서가 더 잘 렌더링되도록 단어 안의 여러 밑줄을 무시합니다.

perform_complicated_task

do_this_and_do_that_and_another_thing

but_emphasis is_desired _here_

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

perform_complicated_task

do_this_and_do_that_and_another_thing

but_emphasis is_desired here

단어의 일부만 강조하려면 별표를 사용하면 됩니다.

perform*complicated*task

do*this*and*do*that*and*another thing

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

performcomplicatedtask

dothisanddothatandanother thing

인라인 diff#

인라인 diff 태그를 사용하면 {+ additions +} 또는 [- deletions -]를 표시할 수 있습니다.

감싸는 태그는 중괄호나 대괄호 중 어느 쪽이든 사용할 수 있습니다.

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

GitLab 인터페이스에서 렌더링된 인라인 diff


그러나 감싸는 태그를 섞어 쓸 수는 없습니다.

- {+ addition +]
- [+ addition +}
- {- deletion -]
- [- deletion -}

diff 강조는 `inline code`에서는 동작하지 않습니다. 텍스트에 백틱(`)이 포함되어 있다면 각 백틱을 백슬래시 \로 이스케이프합니다.

- {+ Just regular text +}
- {+ Text with `backticks` inside +}
- {+ Text with escaped \`backticks\` inside +}

혼합 서식이 적용된 인라인 diff를 GitLab 인터페이스에서 렌더링한 모습

가로줄#

하이픈, 별표, 밑줄을 세 개 이상 사용하여 가로줄을 만듭니다.

---

***

___

렌더링하면 모든 가로줄은 다음과 비슷하게 표시됩니다.


목록#

순서 있는 목록과 순서 없는 목록을 만들 수 있습니다.

순서 있는 목록은 각 줄의 시작에 목록을 시작하려는 숫자(예: 1.)와 공백을 차례로 추가합니다. 첫 번째 숫자 이후에는 어떤 숫자를 써도 상관없습니다. 순서 있는 목록은 세로 순서대로 자동 번호가 매겨지므로, 같은 목록의 모든 항목에 1.을 반복해서 쓰는 것이 일반적입니다. 1.이 아닌 숫자로 시작하면 그 숫자를 첫 번째 숫자로 사용하고 거기서부터 하나씩 늘려 갑니다.

예:

1. First ordered list item
2. Another item
   - Unordered sub-list.
1. Actual numbers don't matter, just that it's a number
   1. Ordered sub-list
   1. Next ordered sub-list item
4. And another item.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
    2. Next ordered sub-list item
  4. And another item.

순서 없는 목록은 각 줄의 시작에 -, *, + 중 하나와 공백을 차례로 추가합니다. 같은 목록에서 이 문자들을 섞어 쓰지 않습니다.

Unordered lists can:

- use
- minuses

They can also:

* use
* asterisks

They can even:

+ use
+ pluses

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Unordered lists can:

  • use
  • minuses

They can also:

  • use
  • asterisks

They can even:

  • use
  • pluses

목록 항목에 문단이 여러 개 있으면 이후의 각 문단을 들여써서

목록 항목 텍스트가 시작하는 위치와 같은 수준에 맞춰야 합니다.

예:

1. First ordered list item

   Second paragraph of first item.

1. Another item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  1. First ordered list item

    Second paragraph of first item.

  2. Another item

첫 번째 항목의 문단을 올바른 개수의 공백으로 들여쓰지 않으면 그 문단은 목록 밖에 표시됩니다. 목록 항목 아래에 올바르게 들여쓰려면 정확한 개수의 공백을 사용합니다. 예:

1. First ordered list item

  (Misaligned paragraph of first item.)

1. Another item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  1. First ordered list item

(Misaligned paragraph of first item.)

  1. Another item

순서 있는 목록이 순서 없는 목록 항목의 첫 번째 하위 항목이고 1.로 시작하지 않는다면, 앞에 빈 줄이 있어야 합니다.

예를 들어 빈 줄이 있는 경우는 다음과 같습니다.

- Unordered list item

  5. First ordered list item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  • Unordered list item

    1. First ordered list item

빈 줄이 없으면 두 번째 목록 항목이 첫 번째 항목의 일부로 렌더링됩니다.

- Unordered list item
  5. First ordered list item

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  • Unordered list item 5. First ordered list item

CommonMark는 순서 있는 목록 항목과 순서 없는 목록 항목 사이의 빈 줄을 무시하고, 이를 하나의 목록으로 간주합니다. 항목은 느슨한 목록으로 렌더링됩니다. 각 목록 항목이 문단 태그로 둘러싸이므로 문단 간격과 여백이 적용됩니다. 그래서 목록의 각 항목 사이에 여분의 간격이 있는 것처럼 보입니다.

예:

- First list item
- Second list item

- A different list

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

  • First list item

  • Second list item

  • A different list

CommonMark는 빈 줄을 무시하고 이를 문단 간격이 적용된 하나의 목록으로 렌더링합니다.

설명 목록#

히스토리
  • 설명 목록이 GitLab 17.7에서 도입되었습니다.

설명 목록은 용어와 그에 대응하는 설명으로 이루어진 목록입니다. 각 용어에는 설명이 여러 개 있을 수 있습니다. HTML에서는 <dl>, <dt>, <dd> 태그로 표현됩니다.

설명 목록을 만들려면 용어를 한 줄에 쓰고, 그다음 줄에 콜론으로 시작하는 설명을 씁니다.

Fruits
: apple
: orange

Vegetables
: broccoli
: kale
: spinach

용어와 설명 사이에 빈 줄을 둘 수도 있습니다.

Fruits

: apple

: orange
Note

리치 텍스트 편집기는 새 설명 목록 삽입을 지원하지 않습니다. 새 설명 목록을 삽입하려면 일반 텍스트 편집기를 사용합니다. 자세한 내용은 이슈 535956을 참고합니다.

작업 목록#

Markdown을 지원하는 모든 위치에 작업 목록을 추가할 수 있습니다.

  • 이슈, 머지 리퀘스트, 에픽, 댓글에서는 체크박스를 선택할 수 있습니다.
  • 그 밖의 모든 위치에서는 체크박스를 선택할 수 없습니다. 대괄호 안에 x를 추가하거나 제거하여 Markdown을 직접 편집해야 합니다.

작업은 완료와 미완료 외에 해당 없음 상태일 수도 있습니다. 이슈, 머지 리퀘스트, 에픽, 댓글에서 해당 없음 체크박스를 선택해도 아무 효과가 없습니다.

작업 목록을 만들려면 순서 있는 목록이나 순서 없는 목록의 형식을 따릅니다.

- [x] Completed task
- [~] Inapplicable task
- [ ] Incomplete task
  - [x] Sub-task 1
  - [~] Sub-task 2
  - [ ] Sub-task 3

1. [x] Completed task
1. [~] Inapplicable task
1. [ ] Incomplete task
   1. [x] Sub-task 1
   1. [~] Sub-task 2
   1. [ ] Sub-task 3

GitLab에서 렌더링된 작업 목록

표 셀에도 작업 목록을 추가할 수 있습니다.

링크#

링크는 여러 방법으로 만들 수 있습니다.

- This line shows an [inline-style link](https://example.com)
- This line shows a [link to a repository file in the same directory](permissions.md)
- This line shows a [relative link to a file one directory higher](../_index.md)
- This line shows a [link that also has title text](https://example.com "This link takes you to Example!")

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

위키 페이지에서 프로젝트 파일을, 또는 프로젝트 파일에서 위키 페이지를 참조하는 데는 상대 링크를 사용할 수 없습니다. GitLab에서 위키는 항상 별도의 Git 리포지터리에 있기 때문에 이러한 제한이 있습니다. 예를 들어 [I'm a reference-style link](style)는 링크가 위키 Markdown 파일 안에 있을 때만 wikis/style을 가리킵니다. 자세한 내용은 위키 전용 Markdown을 참고합니다.

제목 앵커를 사용하여 페이지의 특정 섹션으로 링크합니다.

- This line links to [a section on a different Markdown page, using a `#` and the heading anchor](permissions.md#project-permissions)
- This line links to [a different section on the same page, using a `#` and the heading anchor](#제목-앵커)

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

링크 참조를 사용하는 방법은 다음과 같습니다.

- This line shows a [reference-style link, see below][Arbitrary case-insensitive reference text]
- You can [use numbers for reference-style link definitions, see below][1]
- Or leave it empty and use the [link text itself][], see below.

Some text to show that the reference links can follow later.

[arbitrary case-insensitive reference text]: https://www.mozilla.org/en-US/
[1]: https://slashdot.org
[link text itself]: https://about.gitlab.com/

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Some text to show that the reference links can follow later.

URL 자동 링크#

텍스트에 입력한 거의 모든 URL은 자동으로 링크됩니다.

- https://example.com
- ftp://ftp.us.debian.org/debian/
- smb://foo/bar/baz
- irc://irc.freenode.net/
- http://localhost:3000

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

GitLab 전용 참조#

히스토리
  • 그룹의 레이블을 참조하는 옵션이 GitLab 17.1에서 도입되었습니다.
  • [work_item:123] 구문으로 이슈, 에픽, 작업 항목을 참조하는 옵션:
  • GitLab 18.1에서 extensible_reference_filters라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 18.2에서 정식 출시되었습니다. 기능 플래그 extensible_reference_filters가 제거되었습니다.
  • [epic:123] 구문으로 에픽을 참조하는 옵션이 GitLab 18.4에서 도입되었습니다.
  • 개인 스니펫을 참조하는 기능:
  • GitLab 19.0에서 personal_snippet_reference_filters라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 19.2에서 정식 출시되었습니다. 기능 플래그 personal_snippet_reference_filters가 제거되었습니다.

GitLab Flavored Markdown은 GitLab 전용 참조를 렌더링합니다. 예를 들어 이슈, 커밋, 팀원, 심지어 프로젝트 팀 전체를 참조할 수 있습니다. GitLab Flavored Markdown은 그 참조를 링크로 바꾸므로 서로 이동할 수 있습니다. 프로젝트에 대한 모든 참조는 프로젝트 이름이 아니라 project slug를 사용해야 합니다.

또한 GitLab Flavored Markdown은 특정한 프로젝트 간 참조를 인식하며, 같은 네임스페이스의 다른 프로젝트를 참조하기 위한 단축 표기도 있습니다.

Note

GitLab 전용 참조는 Markdown 스니펫 파일에서 지원되지 않습니다.

GitLab Flavored Markdown은 다음을 인식합니다.

참조 입력 프로젝트 간 참조 같은 네임스페이스 내 단축 표기
특정 사용자 @user_name
특정 그룹 @group_name
팀 전체 @all
프로젝트 namespace/project>
이슈 #123, GL-123, 또는 [issue:123] namespace/project#123 또는 [issue:namespace/project/123] project#123 또는 [issue:project/123]
작업 항목 [work_item:123] [work_item:namespace/project/123] [work_item:project/123]
머지 리퀘스트 !123 namespace/project!123 project!123
스니펫 3 $123 namespace/project$123 project$123
개인 스니펫1 $123
에픽 #123, &123, [work_item:123], 또는 [epic:123] group1/subgroup#123, group1/subgroup&123, [work_item:group1/subgroup/123], 또는 [epic:group1/subgroup/123]
이터레이션 *iteration:"iteration title"
ID로 지정한 이터레이션 케이던스2 [cadence:123]
제목(한 단어)으로 지정한 이터레이션 케이던스2 [cadence:plan]
제목(여러 단어)으로 지정한 이터레이션 케이던스2 [cadence:"plan a"]
취약점 [vulnerability:123] [vulnerability:namespace/project/123] [vulnerability:project/123]
기능 플래그 [feature_flag:123] [feature_flag:namespace/project/123] [feature_flag:project/123]
ID로 지정한 레이블3 ~123 namespace/project~123 project~123
이름(한 단어)으로 지정한 레이블3 ~bug namespace/project~bug project~bug
이름(여러 단어)으로 지정한 레이블3 ~"feature request" namespace/project~"feature request" project~"feature request"
이름(범위 지정)으로 지정한 레이블3 ~"priority::high" namespace/project~"priority::high" project~"priority::high"
ID로 지정한 프로젝트 마일스톤3 %123 namespace/project%123 project%123
이름(한 단어)으로 지정한 마일스톤3 %v1.23 namespace/project%v1.23 project%v1.23
이름(여러 단어)으로 지정한 마일스톤3 %"release candidate" namespace/project%"release candidate" project%"release candidate"
커밋(특정 커밋) 9ba12248 namespace/project@9ba12248 project@9ba12248
커밋 범위 비교 9ba12248...b19a04f5 namespace/project@9ba12248...b19a04f5 project@9ba12248...b19a04f5
리포지터리 파일 참조 [README](doc/README.md)
리포지터리 파일 참조(특정 줄) [README](doc/README.md#L13)
경고 ^alert#123 namespace/project^alert#123 project^alert#123
연락처 [contact:test@example.com]
위키 페이지(페이지 슬러그가 제목과 같은 경우) [[Home]] 또는 [wiki_page:Home] [wiki_page:namespace/project:Home] 또는 [wiki_page:group1/subgroup:Home]
위키 페이지(페이지 슬러그가 제목과 다른 경우) [[How to use GitLab|how-to-use-gitlab]]

예를 들어 #123을 사용하여 이슈를 참조하면 텍스트가 #123인 123번 이슈로의 링크로 출력됩니다. 마찬가지로 123번 이슈로 연결되는 링크도 인식되어 텍스트 #123으로 표시됩니다. #123이 이슈로 링크되는 것을 원하지 않으면 앞에 백슬래시를 붙여 \#123으로 입력합니다.

이와 함께 일부 객체에 대한 링크도 인식되어 서식이 지정됩니다. 예:

  • 이슈의 댓글: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234#note_101075757"은 #1234 (comment 101075757)로 렌더링됩니다.
  • 이슈 디자인 탭: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234/designs"는 #1234 (designs)로 렌더링됩니다.
  • 개별 디자인 링크: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234/designs/layout.png"는 #1234[layout.png]로 렌더링됩니다.

항목 제목 표시#

히스토리
  • 에픽 지원이 GitLab 17.7에서 work_item_epics라는 플래그와 함께 도입되었으며, 기본적으로 활성화되어 있습니다.
  • 에픽에 대해 GitLab 18.1에서 정식 출시되었습니다. 기능 플래그 work_item_epics가 제거되었습니다.

이슈, 태스크, 목표, 핵심 결과, 머지 리퀘스트, 에픽의 렌더링된 링크에 제목을 포함하려면 다음과 같이 합니다.

  • 참조 끝에 더하기 기호(+)를 추가합니다.

예를 들어 #123+ 같은 참조는 The issue title (#123)로 렌더링됩니다.

https://gitlab.com/gitlab-org/gitlab/-/issues/1234+ 같은 URL 참조도 확장됩니다.

항목 요약 표시#

히스토리
  • 에픽 지원이 GitLab 17.7에서 work_item_epics라는 플래그와 함께 도입되었으며, 기본적으로 활성화되어 있습니다.
  • 에픽에 대해 GitLab 18.1에서 정식 출시되었습니다. 기능 플래그 work_item_epics가 제거되었습니다.

에픽, 이슈, 태스크, 목표, 핵심 결과, 머지 리퀘스트의 렌더링된 링크에 확장 요약을 포함하려면 다음과 같이 합니다.

  • 참조 끝에 +s를 추가합니다.

요약에는 참조된 항목의 담당자, 마일스톤, 상태(health status) 정보가 작업 항목 유형에 맞게 포함됩니다.

예를 들어 #123+s 같은 참조는 The issue title (#123) • First Assignee, Second Assignee+ • v15.10 • Needs attention로 렌더링됩니다.

https://gitlab.com/gitlab-org/gitlab/-/issues/1234+s 같은 URL 참조도 확장됩니다.

담당자, 마일스톤 또는 상태가 변경되었을 때 렌더링된 참조를 업데이트하려면 다음과 같이 합니다.

  • 페이지를 새로 고칩니다.

마우스를 올렸을 때의 댓글 미리 보기#

히스토리
  • GitLab 17.3에서 comment_tooltips라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 17.6에서 기능 플래그가 제거되었습니다.

댓글로 연결되는 링크에 마우스를 올리면 작성자와 댓글의 첫 줄이 표시됩니다.

Observability 대시보드 삽입#

에픽, 이슈, MR 등의 설명과 댓글에 GitLab Observability UI 대시보드를 삽입할 수 있습니다.

Observability 대시보드 URL을 삽입하려면 다음과 같이 합니다.

  1. GitLab Observability UI에서 주소 표시줄의 URL을 복사합니다.
  2. 댓글이나 설명에 링크를 붙여넣습니다. GitLab Flavored Markdown이 URL을 인식하여 소스를 표시합니다.

표#

표를 만들 때는 다음을 따릅니다.

  • 첫 번째 줄에는 파이프 문자(|)로 구분된 헤더를 넣습니다.
  • 두 번째 줄은 헤더와 셀을 구분합니다.
    • 셀에는 빈 공백, 하이픈, 그리고 (선택 사항으로) 가로 정렬을 위한 콜론만 넣을 수 있습니다.
    • 각 셀에는 하이픈이 하나 이상 있어야 하며, 셀에 하이픈을 더 넣어도 셀의 렌더링은 달라지지 않습니다.
    • 하이픈, 공백, 콜론 이외의 내용은 허용되지 않습니다.
  • 세 번째 줄과 그 이후의 줄에는 셀 값을 넣습니다.
    • Markdown에서 셀을 여러 줄에 걸쳐 나눌 수 없습니다. 한 줄로 유지해야 하지만 매우 길어도 됩니다. 필요하면 HTML <br> 태그를 넣어 줄 바꿈을 강제할 수도 있습니다.
    • 셀의 크기는 서로 같지 않아도 됩니다. 유연하지만 파이프(|)로 구분해야 합니다.
    • 빈 셀을 둘 수 있습니다.
  • 칼럼 너비는 셀의 내용에 따라 동적으로 계산됩니다.
  • 파이프 문자(|)를 표 구분자가 아니라 텍스트로 사용하려면 백슬래시(\|)로 이스케이프해야 합니다.

예:

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

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

header 1 header 2 header 3
cell 1 cell 2 cell 3
cell 4 cell 5 is longer cell 6 is much longer than the others, but that's ok. It eventually wraps the text when the cell is too large for the display size.
cell 7 cell 9

정렬#

또한 두 번째 줄의 "대시" 줄 양쪽에 콜론(:)을 추가하여 칼럼 안 텍스트의 정렬을 선택할 수 있습니다. 이는 칼럼의 모든 셀에 영향을 줍니다.

| Left Aligned | Centered | Right Aligned |
| :----------- | :------: | ------------: |
| Cell 1       | Cell 2   | Cell 3        |
| Cell 4       | Cell 5   | Cell 6        |

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Left Aligned Centered Right Aligned
Cell 1 Cell 2 Cell 3
Cell 4 Cell 5 Cell 6

GitLab에서 표 헤더는 Chrome과 Firefox에서는 항상 왼쪽 정렬이고, Safari에서는 가운데 정렬입니다. 자세한 내용은 표를 참고합니다.

여러 줄이 있는 셀#

HTML 서식을 사용하여 표의 렌더링을 조정할 수 있습니다. 예를 들어 <br> 태그를 사용하면 셀이 여러 줄을 갖도록 강제할 수 있습니다.

| Name  | Details |
| ----- | ------- |
| Item1 | This text is on one line |
| Item2 | This item has:<br>- Multiple items<br>- That we want listed separately |

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Name Details
Item1 This text is on one line
Item2 This item has:
- Multiple items
- That we want listed separately

표 안의 작업 목록#

히스토리
  • 표 셀 안의 작업 항목을 위한 기본 Markdown 구문이 GitLab 18.9에서 도입되었습니다.

Markdown 표 셀에 작업 항목 체크박스를 추가할 수 있습니다. 체크박스는 셀의 유일한 내용이어야 합니다.

| Complete | Task                    |
| -------- | ----------------------- |
|   [x]    | Refactor the backend    |
|   [ ]    | Refactor the frontend   |
|   [~]    | Inapplicable task       |

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Markdown 표에서 렌더링된 작업 목록.

하나의 셀에 작업 항목을 여러 개 추가하거나 추가 텍스트가 있는 작업 항목을 추가하려면, 셀 안에 Markdown을 넣은 HTML 표를 사용합니다.

<table>
<thead>
<tr><th>header 1</th><th>header 2</th></tr>
</thead>
<tbody>
<tr>
<td>cell 1</td>
<td>cell 2</td>
</tr>
<tr>
<td>cell 3</td>
<td>

- [ ] Task one
- [ ] Task two

</td>
</tr>
</tbody>
</table>

리치 텍스트 편집기에서 표를 만든 다음 작업 목록을 삽입할 수도 있습니다.

스프레드시트에서 복사하여 붙여넣기#

스프레드시트 소프트웨어(예: Microsoft Excel, Google Sheets, Apple Numbers)에서 작업하는 경우, 스프레드시트에서 복사하여 붙여넣으면 GitLab이 Markdown 표를 생성합니다. 예를 들어 다음과 같은 스프레드시트가 있다고 가정합니다.

스프레드시트에서 복사

셀을 선택하여 클립보드에 복사합니다. GitLab Markdown 입력란을 열고 스프레드시트를 붙여넣습니다.

Markdown 표로 붙여넣기

표 정렬#

히스토리
  • GitLab 19.3에서 markdown_sortable_table_columns라는 기능 플래그와 함께 베타로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 19.5에서 일반 공개되었습니다. 기능 플래그 markdown_sortable_table_columns가 제거되었습니다.

렌더링된 표에서는 칼럼의 값을 기준으로 행을 정렬할 수 있습니다.

표를 정렬하려면 다음과 같이 합니다.

  1. 칼럼 헤더에서 Sort ascending([sort-lowest])을 선택합니다.
  2. Sort descending([sort-highest])을 선택합니다.
  3. 행의 원래 순서를 복원하려면 Reset sorting([redo])을 선택합니다.

텍스트와 빈 공간을 포함해 칼럼 헤더 셀의 어느 곳을 선택해도 같은 정렬 동작을 수행할 수 있습니다. 헤더에 있는 링크는 표를 정렬하지 않고 열립니다.

버튼의 아이콘과 툴팁은 다음에 수행할 동작을 보여 줍니다. 툴팁을 보려면 버튼 위에 마우스를 올리거나 키보드 포커스를 버튼으로 이동합니다. 키보드로 정렬하려면 칼럼 헤더 또는 해당 정렬 버튼으로 포커스를 이동하고 Enter 또는 Space를 누릅니다.

정렬 동작은 다음과 같습니다.

  • 값은 알파벳순으로 정렬되며 대소문자를 구분하지 않습니다.
  • 숫자와 날짜는 숫자 값이나 시간순이 아니라 텍스트로 정렬됩니다.
  • 빈 셀은 오름차순과 내림차순 모두에서 항상 표의 맨 아래로 정렬됩니다.

한 번에 하나의 칼럼만 기준으로 정렬할 수 있습니다. 다른 칼럼을 기준으로 정렬하면 이전 정렬이 해제됩니다.

제외 대상은 다음과 같습니다.

JSON 표#

히스토리
  • Markdown 렌더링이 GitLab 17.9에서 도입되었습니다.

JSON 코드 블록으로 표를 렌더링하려면 다음 구문을 사용합니다.

```json:table
{}
```

이 기능을 안내하는 다음 동영상을 시청합니다.

동영상 보기: Demo: JSON Tables in Markdown.

items 속성은 데이터 포인트를 나타내는 객체의 목록입니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ]
}
```

표 레이블을 지정하려면 fields 속성을 사용합니다.

```json:table
{
    "fields" : ["a", "b", "c"],
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ]
}
```

items의 모든 요소가 fields에 대응하는 값을 가질 필요는 없습니다.

```json:table
{
    "fields" : ["a", "b", "c"],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "c": "233"}
    ]
}
```

fields를 명시적으로 지정하지 않으면 레이블은 items의 첫 번째 요소에서 가져옵니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "c": "233"}
    ]
}
```

fields에 사용자 지정 레이블을 지정할 수 있습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA"},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "b": "222", "c": "233"}
    ]
}
```

fields의 개별 요소에 대해 정렬을 활성화할 수 있습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA", "sortable": true},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "b": "222", "c": "233"}
    ]
}
```

filter 속성을 사용하면 사용자 입력에 따라 내용이 동적으로 필터링되는 표를 렌더링할 수 있습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA"},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "22", "c": "33"},
      {"a": "211", "b": "222", "c": "233"}
    ],
    "filter" : true
}
```

markdown 속성을 사용하면 항목과 캡션에서 GitLab 참조를 포함한 GitLab Flavored Markdown을 사용할 수 있습니다. 필드는 Markdown을 지원하지 않습니다.

```json:table
{
    "fields" : [
        {"key": "a", "label": "AA"},
        {"key": "b", "label": "BB"},
        {"key": "c", "label": "CC"}
    ],
    "items" : [
      {"a": "11", "b": "**22**", "c": "33"},
      {"a": "#1", "b": "222", "c": "233"}
    ],
    "markdown" : true
}
```

기본적으로 모든 JSON 표에는 Generated with JSON data라는 캡션이 있습니다. caption 속성을 지정하여 이 캡션을 재정의할 수 있습니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ],
    "caption" : "Custom caption"
}
```

JSON이 유효하지 않으면 오류가 발생합니다.

```json:table
{
    "items" : [
      {"a": "11", "b": "22", "c": "33"}
    ],
}
```

멀티미디어#

이미지, 동영상, 오디오를 삽입합니다. Markdown 구문으로 파일을 링크하고, 크기를 설정하고, 인라인으로 표시하는 방식으로 멀티미디어를 추가할 수 있습니다. 서식 옵션으로 제목을 지정하고, 너비와 높이를 지정하고, 렌더링된 출력에서 미디어가 표시되는 방식을 제어할 수 있습니다.

이미지#

히스토리
  • 이미지를 오버레이로 여는 기능이 GitLab 18.6에서 도입되었습니다.
  • 투명도 체커보드 전환 기능이 GitLab 18.10에서 도입되었습니다.

!를 앞에 붙인 인라인 또는 참조 링크를 사용하여 이미지를 삽입합니다. 예:

![GitLab logo](img/markdown_logo_v17_11.png "Title Text")

GitLab logo

이미지 링크에서는 다음과 같이 처리됩니다.

  • 대괄호([ ]) 안의 텍스트가 이미지 대체 텍스트가 됩니다.
  • 이미지 링크 경로 뒤의 큰따옴표 안에 있는 텍스트가 제목 텍스트가 됩니다. 제목 텍스트를 보려면 이미지 위에 마우스를 올립니다.

자세한 내용은 접근성을 갖춘 이미지와 동영상을 참고합니다.

이미지를 선택하면 오버레이로 열립니다.

이미지에 투명한 영역이 있으면 이미지 위에 마우스를 올리고 Toggle transparency checkerboard를 선택하여 체커보드 배경을 표시합니다. 체커보드를 사용하면 어떤 테마에서도 투명한 영역을 볼 수 있습니다. Toggle transparency checkerboard는 픽셀의 5% 이상이 어느 정도 투명한(완전히 불투명하지 않은) PNG, WebP, GIF 이미지에 표시됩니다. 투명한 픽셀이 5% 미만인 이미지에는 이 전환 버튼이 표시되지 않습니다.

동영상#

동영상 확장자를 가진 파일을 링크하는 이미지 태그는 자동으로 동영상 플레이어로 변환됩니다. 유효한 동영상 확장자는 .mp4, .m4v, .mov, .webm, .ogv입니다.

다음은 동영상 예제입니다.

![Sample Video](img/markdown_video.mp4)

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

Sample Video

이미지 또는 동영상 크기 변경#

이미지나 동영상 뒤에 속성 목록을 추가하여 너비와 높이를 제어할 수 있습니다. 값은 단위가 px(기본값) 또는 %인 정수여야 합니다.

예:

![GitLab logo](img/markdown_logo_v17_11.png "Title Text"){width=100 height=100px}

![GitLab logo](img/markdown_logo_v17_11.png "Title Text"){width=75%}

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

GitLab logo{width=100 height=100px}

Markdown 대신 img HTML 태그를 사용하고 height와 width 매개변수를 설정할 수도 있습니다.

GitLab 17.1 이상에서 해상도가 높은 PNG 이미지를 Markdown 텍스트 상자에 붙여넣으면 크기가 항상 함께 추가됩니다. 이 크기는 레티나(및 기타 고해상도) 디스플레이에 맞게 자동으로 조정됩니다. 예를 들어 144ppi 이미지는 원래 크기의 50%로, 96ppi 이미지는 원래 크기의 75%로 조정됩니다.

이미지를 선택하면 100% 또는 창에 맞는 가장 큰 크기 중 하나로 조정되어 오버레이로 열립니다.

오디오#

동영상과 마찬가지로, 오디오 확장자를 가진 파일의 링크 태그는 자동으로 오디오 플레이어로 변환됩니다. 유효한 오디오 확장자는 .mp3, .oga, .ogg, .spx, .wav입니다.

다음은 오디오 클립 예제입니다.

![Sample Audio](img/markdown_audio.mp3)

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

Sample Audio

삽입된 콘텐츠#

히스토리
  • GitLab 18.5에서 allow_iframes_in_markdown라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • 삽입 공급자가 GitLab 19.5에서 도입되었습니다. 삽입 공급자가 도메인 허용 목록을 대체합니다.
Feature flag

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로 사용할 수 있으며, 프로덕션에서 사용할 준비가 되지 않았습니다.

허용된 삽입 공급자의 콘텐츠로 연결되는 이미지 태그는 삽입된 콘텐츠로 렌더링됩니다. 콘텐츠는 샌드박스 프레임에서 로드되며, 로드되는 위치를 보여 주는 레이블이 함께 표시됩니다. 일부 공급자는 콘텐츠가 로드되기 전에 Load external content를 선택해야 합니다. URL이 허용된 공급자와 일치하지 않으면 표준 이미지로 렌더링됩니다.

사용 가능한 삽입 공급자는 GitLab이 정의합니다. 관리자가 허용할 공급자를 선택합니다.

  • Admin 영역의 Settings > General에 있는 Embedded content 섹션에서 선택합니다.
  • 애플리케이션 설정 API의 iframe_rendering_enabled 및 iframe_rendering_allowlist 속성으로 선택합니다.

다음 삽입 공급자를 사용할 수 있습니다.

공급자 ID 허용되는 URL
YouTube youtube https://www.youtube.com/watch?v=<id>, https://youtu.be/<id> 또는 https://www.youtube.com/embed/<id>
Figma figma https://www.figma.com/<type>/<id> 또는 https://embed.figma.com/<type>/<id>. <type>은 proto, design, board, file, slides 중 하나입니다

공급자의 <iframe> 삽입 코드를 붙여넣을 수도 있습니다.

예를 들어 YouTube 공급자가 허용된 경우:

![Demo: JSON Tables in Markdown](https://www.youtube.com/watch?v=12yWKw1AdKY)

인용문#

인용문을 사용하여 참고 사항 같은 정보를 강조합니다. 인용문은 줄을 >로 시작하여 만듭니다.

> Blockquotes help you emulate reply text.
> This line is part of the same quote.

Quote break.

> This very long line is still quoted properly when it wraps. Keep writing to make sure this line is long enough to actually wrap for everyone. You can also *use* **Markdown** in a blockquote.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Blockquotes help you emulate reply text. This line is part of the same quote.

Quote break.

This very long line is still quoted properly when it wraps. Keep writing to make sure this line is long enough to actually wrap for everyone. You can also use Markdown in a blockquote.

여러 줄 인용문#

>>>로 감싸서 여러 줄 인용문을 만듭니다.

>>>
If you paste a message from somewhere else

that spans multiple lines,

you can quote that without having to manually prepend `>` to every line!
>>>

If you paste a message from somewhere else

that spans multiple lines,

you can quote that without having to manually prepend > to every line!

코드 스팬과 코드 블록#

표준 텍스트가 아니라 코드로 보아야 하는 모든 것을 강조합니다.

인라인 코드는 백틱 하나 `로 서식을 지정합니다.

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

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Inline code has back-ticks around it.

더 큰 코드 예제에 비슷한 효과를 내려면 코드 블록을 사용할 수 있습니다. 코드 블록을 만드는 방법은 다음과 같습니다.

  • 코드 블록 전체를 백틱 세 개(```)로 감쌉니다. 여는 쪽과 닫는 쪽의 개수가 같다면 백틱을 세 개보다 많이 사용할 수 있습니다.
  • 코드 블록 전체를 물결표 세 개(~~~)로 감쌉니다.
  • 공백 네 개 이상으로 들여씁니다.

예:

Python code block:

```python
def function():
    #indenting works just fine in the fenced code block
    s = "Python code"
    print(s)
```

Markdown code block using 4 spaces:

    Using 4 spaces
    is like using
    3-backtick fences.

JavaScript code block using tildes:

~~~javascript
const s = "JavaScript syntax highlighting";
alert(s);
~~~

앞의 세 예제는 다음과 같이 렌더링됩니다.

Python code block:

def function():
    #indenting works just fine in the fenced code block
s = "Python code"
print(s)

Markdown code block using 4 spaces:

```plaintext
Using 4 spaces
is like using
3-backtick fences.

JavaScript code block using tildes:

const s = "JavaScript syntax highlighting";
alert(s);

구문 강조#

GitLab은 코드 블록에서 더 다채로운 구문 강조를 위해 Rouge Ruby 라이브러리를 사용합니다. 지원되는 언어 목록은 Rouge 프로젝트 위키를 참고합니다. 구문 강조는 코드 블록에서만 지원되므로 인라인 코드는 강조할 수 없습니다.

코드 블록을 감싸고 구문 강조를 적용하려면 여는 코드 선언에서 백틱 세 개(```) 또는 물결표 세 개(~~~) 뒤에 코드 언어를 덧붙입니다.

plaintext를 사용하거나 코드 언어를 지정하지 않은 코드 블록에는 구문 강조가 적용되지 않습니다.

```
No language indicated, so **no** syntax highlighting.
s = "No highlighting is shown for this line."
But let's throw in a <b>tag</b>.
```

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

No language indicated, so **no** syntax highlighting.
s = "No highlighting is shown for this line."
But let's throw in a <b>tag</b>.

리포지터리의 코드 삽입#

히스토리
  • GitLab 19.4에서 blob_permalink_embed라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 19.5에서 일반 공개되었습니다. 기능 플래그 blob_permalink_embed가 제거되었습니다.

리포지터리에 있는 파일의 특정 줄에 대한 퍼머링크를 붙여넣으면, GitLab은 그 링크를 해당 줄의 구문 강조된 스니펫으로 바꿉니다. 삽입된 코드의 헤더에는 파일 경로와 삽입된 줄이 표시됩니다. 해당 커밋 시점의 파일로 이동하려면 헤더나 줄 번호를 선택합니다.

리포지터리의 코드를 삽입하려면 다음과 같이 합니다.

  1. 파일의 한 줄 또는 여러 줄 범위에 대한 퍼머링크를 만듭니다.
  2. 댓글이나 설명에서 별도의 문단으로 퍼머링크를 붙여넣습니다.

예:

The external URL is configured here:

https://gitlab.com/gitlab-org/gitlab/-/blob/d768310246d88433a5534576776939d81846f19e/config/gitlab.yml.example#L35-37

퍼머링크는 다음 조건을 충족해야 합니다.

  • 같은 GitLab 인스턴스에 있는 프로젝트를 가리켜야 합니다.
  • 40자 전체 커밋 SHA를 포함해야 합니다. 브랜치 이름이나 태그 이름을 사용하는 링크는 삽입되지 않습니다.
  • #L27 또는 #L27-30 같은 줄 또는 줄 범위 앵커로 끝나야 합니다.
  • 해당 문단의 유일한 내용이어야 하며, 링크 텍스트가 URL과 일치해야 합니다. 일반 텍스트로 붙여넣은 퍼머링크는 이 두 조건을 모두 충족합니다.

제한#

GitLab은 다음을 삽입하지 않습니다.

  • 100줄을 초과하는 범위, 또는 5000번째 줄 이후에서 끝나는 범위.
  • 파일의 마지막 줄 이후에서 시작하는 범위.
  • 바이너리 파일, 10MB보다 큰 파일, Git LFS에 저장된 파일.
  • 하나의 Markdown 문서에서 10개를 초과하는 삽입.

범위가 파일의 마지막 줄 이후에서 끝나더라도 GitLab은 이를 삽입하며, 삽입된 코드는 마지막 줄에서 끝납니다.

프로젝트 간 퍼머링크#

다른 프로젝트에 대한 퍼머링크는 해당 프로젝트의 코드를 볼 수 있는 사용자에게만 삽입됩니다. 다른 사용자에게는 퍼머링크가 그대로 표시되므로, 작성자와 댓글의 독자가 서로 같은 내용을 보지 못할 수 있습니다.

이메일 알림#

GitLab은 다음 두 곳 모두에서 diff 미리 보기가 켜져 있을 때만 이메일 알림에 코드를 삽입합니다.

  • 알림이 발생한 프로젝트 또는 그룹.
  • 퍼머링크가 가리키는 프로젝트.

GitLab은 Service Desk 이메일에는 코드를 삽입하지 않습니다. 이러한 경우 이메일에는 퍼머링크가 그대로 표시됩니다. diff 미리 보기는 프로젝트 또는 그룹의 모든 프로젝트에서 끌 수 있습니다.

다이어그램 및 순서도#

다음을 사용하여 텍스트로 다이어그램을 생성할 수 있습니다.

위키에서는 diagrams.net 편집기로 만든 다이어그램도 추가하고 편집할 수 있습니다.

Mermaid#

히스토리
  • treeView-beta 다이어그램 지원이 GitLab 19.4에서 도입되었습니다.

자세한 내용은 공식 페이지를 참고합니다. Mermaid Live Editor는 Mermaid를 배우고 Mermaid 코드의 문제를 디버그하는 데 도움이 됩니다. 이를 사용하여 다이어그램의 문제를 파악하고 해결합니다.

GitLab은 Mermaid 버전 11을 지원합니다.

다이어그램이나 순서도를 생성하려면 mermaid 블록 안에 텍스트를 작성합니다.

<div class="diagram-placeholder"><div class="diagram-placeholder-header">Mermaid 다이어그램 (8줄)</div><details><summary>소스 코드 보기</summary><pre><code>graph TD
    accTitle: Basic Mermaid diagram example
    accDescr: Simple flowchart showing nodes A, B, C, and D with connections between them.

  A--&gt;B;
  A--&gt;C;
  B--&gt;D;
  C--&gt;D;</code></pre></details></div>

Note

GitLab Self-Managed에서 Cross-Origin-Resource-Policy 헤더를 same-site 또는 same-origin으로 구성한 경우 Mermaid 다이어그램이 아무 오류 표시 없이 렌더링에 실패합니다. 이를 해결하려면 대신 cross-origin을 사용합니다. 자세한 내용은 Cross-Origin-Resource-Policy 헤더와 Mermaid 다이어그램을 참고합니다.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Mermaid 다이어그램 (8줄)
소스 코드 보기
graph TD
    accTitle: Basic Mermaid diagram example
    accDescr: Simple flowchart showing nodes A, B, C, and D with connections between them.

A-->B; A-->C; B-->D; C-->D;

서브그래프도 포함할 수 있습니다.

<div class="diagram-placeholder"><div class="diagram-placeholder-header">Mermaid 다이어그램 (17줄)</div><details><summary>소스 코드 보기</summary><pre><code>graph TB
    accTitle: Mermaid diagram with subgraphs
    accDescr: Flowchart showing main graph with two subgraphs containing nodes and decision flows.

  SubGraph1 --&gt; SubGraph1Flow

  subgraph "SubGraph 1 Flow"
    SubGraph1Flow(SubNode 1)
    SubGraph1Flow -- Choice1 --&gt; DoChoice1
    SubGraph1Flow -- Choice2 --&gt; DoChoice2
  end

  subgraph "Main Graph"
    Node1[Node 1] --&gt; Node2[Node 2]
    Node2 --&gt; SubGraph1[Jump to SubGraph1]
    SubGraph1 --&gt; FinalThing[Final Thing]
  end</code></pre></details></div>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Mermaid 다이어그램 (17줄)
소스 코드 보기
graph TB
    accTitle: Mermaid diagram with subgraphs rendered
    accDescr: Flowchart showing main graph with two subgraphs containing nodes and decision flows as rendered.

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

파일 또는 디렉터리 트리를 렌더링하려면 treeView-beta 다이어그램을 사용합니다. 들여쓰기가 계층 구조를 정의하며, 끝의 /는 디렉터리를 나타냅니다.

<div class="diagram-placeholder"><div class="diagram-placeholder-header">Mermaid 다이어그램 (8줄)</div><details><summary>소스 코드 보기</summary><pre><code>treeView-beta
    accTitle: Mermaid file tree diagram
    accDescr: A file tree with a project directory containing a src directory, index.js, package.json, and a README file.
    my-project/
        src/
            index.js
        package.json
        README.md</code></pre></details></div>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Mermaid 다이어그램 (8줄)
소스 코드 보기
treeView-beta
    accTitle: Mermaid file tree diagram
    accDescr: A file tree with a project directory containing a src directory, index.js, package.json, and a README file.
    my-project/
        src/
            index.js
        package.json
        README.md

PlantUML#

PlantUML 통합은 GitLab.com에서 활성화되어 있습니다. GitLab Self-Managed 설치에서 PlantUML을 사용하려면 GitLab 관리자가 활성화해야 합니다.

PlantUML을 활성화한 후에는 다이어그램 구분자 @startuml/@enduml이 필요하지 않습니다. 이 구분자는 plantuml 블록으로 대체되기 때문입니다. 예:

<div class="diagram-placeholder"><div class="diagram-placeholder-header">PlantUML 다이어그램 (2줄)</div><details><summary>소스 코드 보기</summary><pre><code>Bob -&gt; Alice : hello
Alice -&gt; Bob : hi</code></pre></details></div>

::include 지시문을 사용하여 리포지터리의 별도 파일에서 PlantUML 다이어그램을 포함하거나 삽입할 수 있습니다. 자세한 내용은 다이어그램 파일 포함을 참고합니다.

Kroki#

GitLab에서 Kroki를 사용하려면 GitLab 관리자가 활성화해야 합니다. 자세한 내용은 Kroki 통합 페이지를 참고합니다.

수식#

LaTeX 구문으로 작성한 수식은 KaTeX로 렌더링됩니다. KaTeX는 LaTeX의 일부만 지원합니다. 이 구문은 AsciiDoc 위키와 :stem: latexmath를 사용하는 파일에서도 동작합니다. 자세한 내용은 Asciidoctor 사용자 매뉴얼을 참고합니다.

악의적인 활동을 방지하기 위해 GitLab은 처음 1000개의 인라인 수식 인스턴스만 렌더링합니다. 그룹 또는 전체 GitLab Self-Managed 인스턴스에 대해 이 제한을 비활성화할 수 있습니다.

수식 블록의 수도 렌더링 시간에 따라 제한됩니다. 제한을 초과하면 GitLab은 초과한 수식 인스턴스를 텍스트로 렌더링합니다. 위키와 리포지터리 파일에는 이러한 제한이 없습니다.

백틱을 사용한 달러 기호($`...`$) 또는 달러 기호 하나($...$) 사이에 작성한 수식은 텍스트와 같은 줄에 인라인으로 렌더링됩니다.

달러 기호 두 개($$...$$) 사이에 작성하거나 언어를 math로 선언한 코드 블록에 작성한 수식은 별도의 줄에 렌더링됩니다.

This math is inline: $`a^2+b^2=c^2`$.

This math is on a separate line using a ` ```math ` block:

```math
a^2+b^2=c^2
```

This math is on a separate line using inline `$$`: $$a^2+b^2=c^2$$

This math is on a separate line using a `$$...$$` block:

$$
a^2+b^2=c^2
$$

렌더링하면 예제는 다음과 같이 표시됩니다.

GitLab의 수식 예시

Note

리치 텍스트 편집기는 새 수식 블록 삽입을 지원하지 않습니다. 새 수식 블록을 삽입하려면 일반 텍스트 편집기를 사용합니다. 자세한 내용은 이슈 366527을 참고합니다.

목차#

목차는 문서의 하위 제목으로 연결되는 순서 없는 목록입니다. 이슈, 머지 리퀘스트, 에픽에는 목차를 추가할 수 있지만 노트나 댓글에는 추가할 수 없습니다.

지원되는 콘텐츠 유형의 description 필드에 다음 태그 중 하나를 독립된 줄로 추가합니다.

[[_TOC_]]
or
[TOC]
  • Markdown 파일.
  • 위키 페이지.
  • 이슈.
  • 머지 리퀘스트.
  • 에픽.
Note

대괄호 하나로 감싼 TOC 코드를 사용하면 독립된 줄에 있는지와 관계없이 목차가 렌더링됩니다. 이 동작은 의도된 것이 아닙니다. 자세한 내용은 이슈 359077을 참고합니다.

This is an intro sentence to my wiki page.

[[_TOC_]]

## My first heading

First section content.

## My second heading

Second section content.

위키에서 자동 생성된 목차의 미리 보기

알림#

히스토리
  • GitLab 17.10에서 도입되었습니다.

알림은 무언가를 강조하거나 주의를 환기하는 데 사용할 수 있습니다. 알림 구문은 Markdown 인용문 구문 뒤에 알림 유형을 붙여 사용합니다. Markdown을 지원하는 모든 텍스트 상자에서 알림을 사용할 수 있습니다.

다음 유형의 알림을 사용할 수 있습니다.

  • Note: 훑어보는 경우에도 사용자가 고려해야 하는 정보:

    > [!note]
    > The following information is useful.
    
  • Tip: 사용자가 더 성공적으로 작업하도록 돕는 선택적 정보:

    > [!tip]
    > Tip of the day.
    
  • Important: 사용자가 성공하는 데 필수적인 핵심 정보:

    > [!important]
    > This is something important you should know.
    
  • Caution: 어떤 작업으로 인해 발생할 수 있는 부정적인 결과:

    > [!caution]
    > You need to be very careful about the following.
    
  • Warning: 심각한 잠재적 위험:

    > [!warning]
    > The following would be dangerous.
    

알림에 표시되는 제목 텍스트는 기본적으로 알림의 이름입니다. 예를 들어 > [!warning] 알림의 제목은 Warning입니다.

알림 블록의 제목을 바꾸려면 같은 줄에 원하는 텍스트를 입력합니다. 예를 들어 경고 색상을 사용하되 제목을 Data deletion으로 하려면 다음과 같이 합니다.

> [!warning] Data deletion
> The following instructions will make your data unrecoverable.

여러 줄 인용문도 알림 구문을 지원합니다. 이를 사용하면 길고 복잡한 텍스트를 알림으로 감쌀 수 있습니다.

>>> [!note] Things to consider
You should consider the following ramifications:

1. consideration 1
1. consideration 2
>>>

알림은 다음과 같이 렌더링됩니다.

GitLab에서 Markdown 알림이 렌더링되는 모습

색상#

Markdown은 텍스트 색상 변경을 지원하지 않습니다.

색상 코드는 HEX, RGB, HSL 형식으로 작성할 수 있습니다.

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

이름으로 지정하는 색상은 지원되지 않습니다.

GitLab 애플리케이션에서는(GitLab 문서에서는 제외) 백틱으로 감싼 색상 코드 옆에 색상 칩이 표시됩니다. 예:

- `#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)`

이 예제는 GitLab에서 렌더링될 때만 동작합니다.

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

색상 코드 이스케이프#

히스토리
  • GitLab 18.3에서 도입되었습니다.

색상 칩을 생성하지 않고 색상 코드를 인라인 코드로 표시하려면 앞에 백슬래시(\)를 붙입니다.

예:

  • \#FF0000
  • \RGB(255,0,0)
  • \HSL(0,100%,50%)

모든 경우에 백슬래시는 제거되며 출력에는 색상 칩이 렌더링되지 않습니다.

이슈 번호 같은 값을 의도치 않게 색상 칩이 생기지 않도록 인라인 코드에 포함하려는 경우에 사용합니다.

이모지#

GitLab Flavored Markdown을 지원하는 모든 위치에서 이모지를 사용할 수 있습니다. 예:

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

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 :heart: you for that.

If you're new to this, don't be :fearful:. You can join the emoji :family:.
Just look up one of the supported codes.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

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

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

If you're new to this, don't be :fearful:. You can join the emoji :family:. Just look up one of the supported codes.

지원되는 모든 이모지 코드 목록은 이모지 치트 시트를 참고합니다.

이모지와 운영 체제#

앞의 이모지 예제는 하드코딩된 이미지를 사용합니다. GitLab에서 렌더링되는 이모지는 사용하는 OS와 브라우저에 따라 다르게 보일 수 있습니다.

대부분의 이모지는 macOS, Windows, iOS, Android에서 기본적으로 지원되며, 지원되지 않는 환경에서는 이미지 기반 이모지로 대체됩니다.

Linux에서는 Noto Color Emoji를 다운로드하면 이모지를 기본으로 완전히 지원할 수 있습니다. Ubuntu 22.04는(최신 Linux 배포판 대부분과 마찬가지로) 이 글꼴이 기본으로 설치되어 있습니다.

사용자 지정 이모지 추가에 대한 자세한 내용은 사용자 지정 이모지를 참고합니다.

프런트 매터#

프런트 매터는 Markdown 문서의 맨 앞, 내용보다 앞에 포함되는 메타데이터입니다. 이 데이터는 Jekyll, Hugo 같은 정적 사이트 생성기와 그 밖의 많은 애플리케이션에서 사용할 수 있습니다.

GitLab이 렌더링한 Markdown 파일을 볼 때 프런트 매터는 문서 맨 위의 상자 안에 있는 그대로 표시됩니다. HTML 콘텐츠는 프런트 매터 뒤에 표시됩니다. 예시를 보려면 GitLab 문서 파일에서 원본 보기와 렌더링 보기를 전환해 볼 수 있습니다.

GitLab에서 프런트 매터는 Markdown 파일과 위키 페이지에서만 사용되며, Markdown 서식을 지원하는 다른 위치에서는 사용되지 않습니다. 프런트 매터는 문서의 맨 위에 있어야 하며 구분자 사이에 있어야 합니다.

다음 구분자가 지원됩니다.

  • YAML(---):

    ---
    title: About Front Matter
    example:
      language: yaml
    ---
    
  • TOML(+++):

    +++
    title = "About Front Matter"
    [example]
    language = "toml"
    +++
    
  • JSON(;;;):

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

기존 구분자에 지정자를 추가하면 다른 언어도 지원됩니다. 예:

---php
$title = "About Front Matter";
$example = array(
  'language' => "php",
);
---

포함#

히스토리
  • GitLab 17.7에서 도입되었습니다.

포함(include) 또는 포함 지시문을 사용하면 한 문서의 내용을 다른 문서 안에 추가할 수 있습니다.

예를 들어 책을 여러 장으로 나눈 다음, 각 장을 메인 책 문서에 포함할 수 있습니다.

::include{file=chapter1.md}

::include{file=chapter2.md}

GitLab에서 포함 지시문은 Markdown 파일과 위키 페이지에서만 사용되며, Markdown 서식을 지원하는 다른 위치에서는 사용되지 않습니다.

Markdown 파일에서 포함 지시문을 사용하는 방법은 다음과 같습니다.

::include{file=example_file.md}

위키 페이지에서 포함 지시문을 사용하는 방법은 다음과 같습니다.

::include{file=example_page.md}

각 ::include는 줄의 시작에서 시작해야 하며, file=에 파일 또는 URL을 지정합니다. 지정한 파일(또는 URL)의 내용은 ::include의 위치에 포함되고 나머지 Markdown과 함께 처리됩니다.

포함된 파일 안의 포함 지시문은 무시됩니다. 예를 들어 file1이 file2를 포함하고 file2가 file3을 포함하는 경우, file1을 처리할 때 file3의 내용은 포함되지 않습니다.

포함 제한#

좋은 시스템 성능을 보장하고 악의적인 문서가 문제를 일으키는 것을 방지하기 위해 GitLab은 문서에서 처리하는 포함 지시문의 수에 최대 제한을 둡니다. 기본적으로 문서에는 포함 지시문을 최대 32개까지 둘 수 있습니다.

처리되는 포함 지시문의 수를 조정하려면 관리자가 애플리케이션 설정 API로 asciidoc_max_includes 애플리케이션 설정을 변경할 수 있습니다.

외부 URL의 포함 사용#

별도의 위키 페이지나 외부 URL의 포함을 사용하려면 관리자가 wiki_asciidoc_allow_uri_includes 애플리케이션 설정을 활성화할 수 있습니다.

<!-- define application setting wiki_asciidoc_allow_uri_includes to true to allow content to be read from URI -->
::include{file=https://example.org/installation.md}

코드 블록에서 포함 사용#

코드 블록 안에서 ::include 지시문을 사용하여 리포지터리의 파일에 있는 내용을 추가할 수 있습니다. 예를 들어 리포지터리에 javascript_code.js 파일이 있다고 가정합니다.

const s = "JavaScript syntax highlighting";
alert(s);

이를 Markdown 파일에 포함할 수 있습니다.

Our script contains:

```javascript
::include{file=javascript_code.js}
```

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Our script contains:

const s = "JavaScript syntax highlighting";
alert(s);

플레이스홀더#

히스토리
Feature flag

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로 사용할 수 있으며, 프로덕션에서 사용할 준비가 되지 않았습니다.

플레이스홀더를 사용하면 프로젝트의 제목이나 최신 태그처럼 변경될 수 있는 특정 유형의 데이터를 표시할 수 있습니다. 플레이스홀더는 Markdown이 렌더링될 때마다 채워집니다.

구문은 %{PLACEHOLDER}입니다.

플레이스홀더 예시 값 설명
%{gitlab_server} gitlab.com 프로젝트의 서버
%{gitlab_pages_domain} pages.gitlab.com GitLab Pages를 호스팅하는 도메인
%{project_path} gitlab-org/gitlab 상위 그룹을 포함한 프로젝트의 경로
%{project_name} gitlab 프로젝트의 이름
%{project_id} 278964 프로젝트와 연결된 데이터베이스 ID
%{project_namespace} gitlab-org 프로젝트의 프로젝트 네임스페이스
%{project_title} GitLab 프로젝트의 제목
%{group_name} gitlab-org 프로젝트가 속한 그룹
%{default_branch} main 프로젝트 리포지터리에 구성된 기본 브랜치 이름
%{current_ref} feature-branch 현재 보고 있는 ref(브랜치, 태그 또는 커밋 SHA)
%{commit_sha} ad10e011ce65492322037633ebc054efde37b143 프로젝트 리포지터리의 기본 브랜치에 대한 가장 최근 커밋의 ID
%{latest_tag} v17.10.7-ee 프로젝트 리포지터리에 추가된 최신 태그
%{merge_request_iid} 57 머지 리퀘스트 URL의 프로젝트 수준 IID. 머지 리퀘스트를 생성한 후에만 사용할 수 있습니다.

이스케이프 문자#

Markdown은 페이지 서식을 지정하기 위해 다음 ASCII 문자를 예약해 두었습니다.

! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

텍스트에서 이러한 예약 문자 중 하나를 사용하려면 예약 문자 바로 앞에 백슬래시 문자(\)를 추가합니다. 예약 문자 앞에 백슬래시를 두면 Markdown 파서는 백슬래시를 생략하고 예약 문자를 일반 텍스트로 처리합니다.

예:

\# Not a heading

| Food  | Do you like this food? (circle) |
|-------|---------------------------------|
| Pizza | Yes \| No                       |

\**Not bold, just italic text placed between some asterisks*\*

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

# Not a heading

Food Do you like this food? (circle)
Pizza Yes | No

*Not bold, just italic text placed between some asterisks*

백슬래시가 항상 뒤따르는 문자를 이스케이프하는 것은 아닙니다. 다음 경우에는 백슬래시가 일반 텍스트로 표시됩니다.

  • 백슬래시가 A, 3, 공백처럼 예약되지 않은 문자 앞에 있는 경우.
  • 백슬래시가 다음 Markdown 요소 안에 있는 경우.
    • 자동 링크
    • <kbd> 같은 인라인 HTML
    • 코드 블록
    • 코드 스팬

이러한 경우에는 ]에 대한 &#93;처럼 그에 해당하는 HTML 엔티티를 사용해야 할 수 있습니다.

백틱 추가 사용#

앞의 안내는 리터럴 내용이 항상 그대로 표시되는 코드 블록이나 코드 스팬에는 적용되지 않습니다. 대신 백틱을 추가로 사용하여 코드를 중첩합니다.

코드 블록에 백틱 세 개를 포함해야 한다면, 코드 블록을 만들 때 더 많은 개수의 백틱을 사용합니다.

To create a code block in Markdown, use three or more matching backticks:

````markdown
```
code
```
````

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

To create a code block in Markdown, use three or more matching backticks:

```
code
```

코드 스팬에 백틱을 하나 이상 포함하려면 코드 스팬을 만들 때 더 많은 개수의 짝이 맞는 백틱을 사용합니다. 내용이 공백으로 시작하고 끝나면 그 공백도 제거됩니다.

To create a code span in Markdown, use matching backticks: `` `hello, world` ``

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

To create a code span in Markdown, use matching backticks: `hello, world`

백틱과 백슬래시 함께 사용#

백슬래시(\) 문자가 인라인 코드 샘플의 끝에 있으면 백슬래시가 마지막 백틱을 이스케이프할 수 있습니다. 이 경우 인라인 코드 주위에 공백을 추가합니다. 예:

Use the backslash ` \ ` character to escape inline code that ends in a ` backslash\ `.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Use the backslash \ character to escape inline code that ends in a backslash\.

각주#

각주는 Markdown 파일의 끝에 렌더링되는 주석으로 연결되는 링크를 추가합니다.

각주를 만들려면 참조 태그와, (파일의 어느 위치든) 주석 내용이 있는 별도의 줄이 모두 필요합니다.

태그 이름과 관계없이 참조 태그의 상대적인 순서가 렌더링되는 번호를 결정합니다.

주석을 어디에 두든 항상 렌더링된 파일의 맨 아래에 표시됩니다.

Note

리치 텍스트 편집기는 새 각주 삽입을 지원하지 않습니다. 새 각주를 삽입하려면 일반 텍스트 편집기를 사용합니다. 자세한 내용은 이슈 365265를 참고합니다.

예:

  • 각주 참조:

    A footnote reference tag looks like this:[^1]
    
    This reference tag is a mix of letters and numbers. [^footnote-42]
    
  • 파일의 다른 부분에서 각주 정의:

    [^1]: This text is inside a footnote.
    [^footnote-42]: This text is another footnote.
    

렌더링하면 각주는 다음과 비슷하게 표시됩니다.

A footnote reference tag looks like this:4

This reference tag is a mix of letters and numbers.5

인라인 HTML#

Markdown에서 원시 HTML도 사용할 수 있으며, 대개 꽤 잘 동작합니다.

허용되는 HTML 태그와 속성 목록은 HTML::Pipeline의 SanitizationFilter 클래스 문서를 참고합니다. 기본 SanitizationFilter 허용 목록 외에도 GitLab은 span, abbr, details, summary 요소를 허용합니다. Rel-License 마이크로포맷과 라이선스 표기를 지원하기 위해 링크에는 rel="license"가 허용됩니다.

<dl>
  <dt>Definition list</dt>
  <dd>Is something people use sometimes.</dd>

  <dt>Markdown in HTML</dt>
  <dd>Does *not* work **very** well. HTML <em>tags</em> do <b>work</b>, in most cases.</dd>
</dl>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. HTML tags do work, in most cases.

HTML 태그 안에서도 Markdown을 사용할 수 있지만, Markdown이 들어 있는 줄을 별도의 줄로 분리한 경우에만 가능합니다.

<dl>
  <dt>Markdown in HTML</dt>
  <dd>

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

  </dd>
</dl>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Markdown in HTML

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

접을 수 있는 섹션#

HTML의 <details> 및 <summary> 태그를 사용하여 콘텐츠를 접을 수 있습니다. 예를 들어 긴 로그 파일을 접어 화면을 덜 차지하게 합니다.

<details>
<summary>Click to expand</summary>

These details <em>remain</em> <strong>hidden</strong> until expanded.

<pre><code>PASTE LOGS HERE</code></pre>

</details>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Click to expand

These details remain hidden until expanded.

PASTE LOGS HERE

이 태그 안의 Markdown도 지원됩니다.

예제와 같이 모든 Markdown 섹션의 앞뒤에 빈 줄을 남겨 두어야 합니다.

<details>
<summary>

Click to _expand._

</summary>

These details _remain_ **hidden** until expanded.

```
PASTE LOGS HERE
```

</details>

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Click to expand.

These details remain hidden until expanded.

PASTE LOGS HERE

키보드 HTML 태그#

<kbd> 요소는 사용자의 키보드 입력을 나타내는 텍스트를 식별하는 데 사용됩니다. <kbd> 태그로 감싼 텍스트는 일반적으로 브라우저의 기본 고정폭 글꼴로 표시됩니다.

Press <kbd>Enter</kbd> to go to the next page.

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

Press Enter to go to the next page.

위 첨자와 아래 첨자#

GitLab Flavored Markdown은 Redcarpet의 위 첨자 구문( x^2 )을 지원하지 않습니다. 위 첨자와 아래 첨자에는 표준 HTML 구문을 사용합니다.

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

렌더링하면 예제는 다음과 비슷하게 표시됩니다.

The formula for water is H2O while the equation for the theory of relativity is E = mc2.

GitLab Flavored Markdown은 Redcarpet의 위 첨자 구문( x^2 )을 지원하지 않습니다.

HTML 주석#

GitLab Flavored Markdown에서 HTML 주석을 사용하면 렌더링된 출력에는 보이지 않는 메모나 설명을 추가할 수 있습니다.

HTML 주석은 다음 용도로 사용합니다.

  • 다른 기여자를 위한 메모를 추가합니다.
  • 콘텐츠를 삭제하지 않고 임시로 숨깁니다.
  • 최종 문서에 표시되지 않아야 하는 맥락이나 설명을 제공합니다.
  • 메타데이터나 처리 지침을 추가합니다.

HTML 주석을 사용할 때는 다음을 따르는 것이 좋습니다.

  • 소스가 어수선해지지 않도록 필요한 만큼만 사용합니다.
  • 간결하고 관련성 있게 작성합니다.
  • 영구적인 문서화가 아니라 임시 메모에 사용합니다.
  • 민감하거나 기밀인 정보를 포함하지 않습니다. HTML 주석은 Markdown 소스를 볼 수 있는 누구에게나 보입니다.

HTML 주석은 표준 HTML 구문 <!-- comment text -->을 사용하며 한 줄 또는 여러 줄로 작성할 수 있습니다.

<!-- This is a single-line comment -->

<!--
This is a multi-line comment
that spans several lines
and won't be visible in the rendered output
-->

This text is visible.
<!-- This comment between paragraphs is hidden -->
This text is also visible.

렌더링하면 보이는 텍스트만 표시됩니다.

This text is visible.

This text is also visible.

코드 블록 안의 주석#

코드 블록 안의 HTML 주석은 리터럴 텍스트로 처리되어 그대로 표시됩니다.

```html
<!-- This comment will be visible in the code block -->
<div>Content</div>

```

Footnotes

  1. 스니펫 ID는 개인 스니펫과 프로젝트 스니펫 전체에서 고유하므로, 특정 ID는 항상 하나의 스니펫만 식별합니다. ↩

  2. 이터레이션 케이던스 참조는 항상 [cadence:] 형식으로 렌더링됩니다. 예를 들어 참조된 이터레이션 케이던스의 ID가 1이면 텍스트 참조 [cadence:"plan"]은 [cadence:1]로 렌더링됩니다. ↩ ↩2 ↩3

  3. 레이블이나 마일스톤의 경우 namespace/project 앞에 /를 붙여 정확한 레이블 또는 마일스톤을 지정하면, 발생할 수 있는 모호함이 없어집니다. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  4. This text is inside a footnote. ↩

  5. This text is another footnote. ↩