GitLab 음성
문서는 참중이라는 싱글 소스입니다(SSoT)
주제 유형
문서 우선 방법
로컬라이제이션을 위한 작성
Markdown
- Markdown에서의 HTML
- Markdown에서의 제목 레벨
- Markdown에서의 역따옴표
언어
- 능동태
- 고객 관점
- 신뢰 구축
- 대문자 사용
- 숫자
텍스트
- 행 길이
- 코멘트
- 강조
- 구두점
- 자리 표시자 텍스트
- 키보드 명령
- UI의 버튼
- UI에 입력된 텍스트
- 인라인 코드
- 코드 블록
  - 코드 블록에서의 cURL 명령
디렉터리
- 순서가 있는 디렉터리 또는 순서가 없는 디렉터리 중 선택
- 디렉터리 마크업
- 디렉터리 항목 안의 중첩
테이블
- 생성 가이드라인
- 테이블 형식팅을 위한 편집기 확장 기능
- 기존 테이블의 업데이트
- 테이블 헤더
- 기능 테이블
- 각주
  - 각주 형식
    - 다섯 개 이상의 각주
- 코드의 특정 라인에 대한 링크
내비게이션
- 메뉴 이름
- UI 요소 이름
- 탐색 작업 단계 작성 방법
- 선택사항 단계
- 권장 단계
- 한 번에 여러 필드 문서화
삽화
- 다이어그램
  - 다이어그램 생성
- 화면 캡처
이모지
GitLab SVG 아이콘
비디오
- 비디오 링크
- 비디오 임베드
클릭 스루 데모에 대한 링크
알림 상자
- Flag
- Note
- Warning
- Info
- 고지
- 세부 정보
인용 구역
탭
표절
제품 및 기능
- 이름에 줄 바꿈 피하기
- 제품 티어 뱃지
특정 섹션
- 도움말 및 피드백 섹션
- GitLab 재시작
- 다양한 설치 방법 문서화 방법
- 탭을 사용하여 Self-Managed형 구성 절차 설명
- 버전 업그레이드를 위한 변경 사항

문서 스타일 가이드

이 문서는 GitLab 문서의 표준을 정의하며, 맞춤법, 서식 및 기타 사항을 포함합니다. 특정 단어에 대한 지침은 단어 디렉터리을 참조하세요.

스타일 문제에 대해서는 문제나 Merge Request에서 @tw-style을 언급하십시오. GitLab Slack 워크스페이스에 액세스할 수 있는 경우 #docs-processes 채널을 사용하십시오.

GitLab 음성

GitLab 브랜드 매뉴얼에서는 큰 조직이 사용하는 음성을 정의합니다.

이러한 지침을 기반으로 GitLab 문서의 음성은 간결하고 명확하며 정확하려고 노력합니다. 목표는 검색하고 스캔하기 쉬운 정보를 제공하는 것입니다.

문서의 음성은 대화식이면서 간결하며 친근하면서도 간결해야합니다.

문서는 참중이라는 싱글 소스입니다(SSoT)

GitLab 문서는 구현, 사용 및 문제 해결과 관련된 모든 제품 정보에 대한 SSoT입니다. 문서는 지속적으로 발전하며 새로운 제품 및 기능으로 업데이트되며 명료성, 정확성 및 완전성을 높이기 위한 개선사항이 있습니다.

이 정책은 정보 격리를 방지하여 GitLab 제품에 대한 정보를 찾기 쉽게 만듭니다. 또한 문서에 포함될 내용의 종류에 대한 결정에 영향을 미칩니다.

주제 유형

GitLab은 주제 유형을 사용하여 제품 문서를 구성합니다.

주제 유형은 사용자가 정보를 더 빨리 소화하는 데 도움이 됩니다. 또한 다음 문제를 해결하는 데 도움이 됩니다.

콘텐츠를 찾기 어렵습니다. GitLab 문서는 포괄적이며 많은 양의 유용한 정보를 포함합니다. 주제 유형은 콘텐츠를 더 쉽게 스캔하고 파싱할 수 있는 반복 가능한 패턴을 만듭니다.
콘텐츠는 종종 기여자의 관점에서 작성됩니다. GitLab 문서는 다양한 기여자들이 작성합니다. 주제 유형(특히 작업)은 기능이 어떻게 구현되었는지가 아닌 다른 사람들을 돕기 위해 포맷에 정보를 넣도록 돕습니다.

문서 우선 방법

제품 문서는 완벽하고 신뢰할 수 있는 리소스여야 합니다.

질문에 대답이 문서에 있는 경우, 정보를 다시 말하는 대신 문서의 링크를 공유하십시오.
GitLab 문서에 사용 가능하지 않은 정보를 만나면, 해당 정보를 추가하기 위해 Merge Request(MR)를 작성하고, 그런 다음 MR을 공유하여 정보를 전달하십시오.

우리가 반사적으로 문서에 정보를 추가할수록, 문서가 다른 사람들이 효율적으로 작업을 수행하고 문제를 해결하는 데 도움을 줍니다.

로컬라이제이션을 위한 작성

GitLab 문서는 로컬라이제이션되지는 않지만, 전역 수용자를 위해 작성하는 데 도움이 되는 지침을 따릅니다.

GitLab 음성에 따라 번역을 염두에 두고 명확하고 직접적으로 작성합니다. 저희의 스타일 가이드, 단어 디렉터리 및 Vale 규칙은 문서의 일관성을 보장합니다.

문서가 다른 언어로 번역될 때에는 각 단어의 의미가 명확해야합니다. 기계 번역, GitLab Duo Chat 및 기타 AI 도구의 증가로 일관성이 더욱 중요해집니다.

다음 규칙은 문서가 효율적으로 번역되는 데 도움이 될 수 있습니다.

회피:

주어를 숨기는 구문 (예: there is 및 there are 같은).
모호한 대명사 (예: it).
-ing로 끝나는 단어들.
서로 헷갈릴 수 있는 단어들 (예: since 와 because).
예 및 즉와 같은 라틴 약어.
kill two birds with one stone과 같은 문화에 따른 언급들.

사용:

표준 링크의 텍스트.
복잡한 문장과 단락 대신 디렉터리 및 표.
AI 및 CI/CD와 같은 일반 약어 및 이전에 철자로 풀어 썼던 약어들.

또한, 다음 지침을 명심하십시오:

기능명과 상호 작용하는 방법에 일관성을 유지하십시오.
명사 문자열을 나누십시오. 예를 들어 project integration custom settings 대신에 custom settings for project integrations를 사용하십시오.
국제 수준의 일관된 형식으로 날짜 및 시간을 형식화하십시오.
스크린샷을 포함하여 가능한 적게 사용하십시오.
UI 텍스트의 경우, 번역에서 30% 까지 확장 및 수축이 가능하도록 해주십시오. 다른 언어로 문자열이 얼마나 확장되거나 수축되는지 확인하려면 문자열을 Google 번역에 붙여 넣고 결과를 검토하십시오. 해당 언어를 구사하는 동료에게 번역이 명확한지 검증해달라고 할 수 있습니다.

Markdown

모든 GitLab 문서는 Markdown으로 작성됩니다.

문서 웹사이트는 Markdown에서 HTML로 페이지를 렌더링하는 “풍미있는” Kramdown 엔진인 GitLab Kramdown을 사용합니다. Kramdown 기능은 우리의 린터에 의해 제한되므로 일반 Markdown을 사용하고 링크된 스타일 가이드의 규칙을 준수하십시오. 특정 Kramdown 마크업(예: {:.class})은 사용할 수 없습니다.

완전한 Kramdown 참조를 보려면 GitLab Markdown 가이드를 참조하십시오.

Markdown 형식은 markdownlint와 Vale를 사용하여 테스트됩니다.

Markdown에서의 HTML

Hard-coded HTML은 유효하지만 사용을 자제해야 합니다. HTML은 다음과 같은 경우에 허용됩니다.

Markdown에 해당하는 마크업이 없는 경우.
고급 표가 필요한 경우.
특별한 스타일링이 필요한 경우.
기술 작성자에 의해 검토 및 승인된 경우.

Markdown에서의 제목 레벨

각 문서 페이지는 레벨 1 제목(#)로 시작합니다. 이것은 페이지가 HTML로 렌더링될 때 h1 요소가 됩니다. 페이지 당 한 개의 레벨 1 제목만 있을 수 있습니다.

각 하위 섹션에 대해 제목 레벨을 증가시킵니다. 다시 말해, 주제 제목 앞의 # 문자 수를 증가시키십시오.
H5(#####) 이상의 제목 레벨을 피하십시오. 다섯 개 이상의 제목 레벨이 필요한 경우, 대신에 주제를 새로운 페이지로 이동하십시오. H5보다 큰 제목 레벨은 오른쪽 사이드바 탐색에 표시되지 않습니다.
제목 레벨을 건너뛰지 마십시오. 예를 들어: ## > ####.
주제 제목 앞 뒤로 한 줄의 공백을 남겨두십시오.
주제 제목에서 코드를 사용하는 경우, 코드가 역따옴표로 둘러싸여 있는지 확인하십시오.

Markdown에서의 역따옴표

다음에 사용하십시오.

코드 블록.
오류 메시지.
명령, 매개변수 및 파일 이름.
값. 예: “ Name 텍스트 상자에 test를 입력하십시오.”

언어

GitLab 문서는 명확하고 이해하기 쉽게 작성되어야 합니다.

불필요한 단어를 피하십시오.
명확하고 간결하게 작성하고 주제의 목표를 지켜야 합니다.
US 영어와 US 문법으로 작성하십시오. British.yml에서 테스트됩니다.

능동태

대부분의 경우, 주체보다 능동태를 사용하면 텍스트를 이해하고 번역하는 것이 더 쉽습니다.

예를 들어 다음을 사용하십시오.

The developer writes code for the application.

대신에 다음을 사용하십시오.

Application code is written by the developer.

때로는 주제로 GitLab을 사용하는 것이 어색할 수도 있습니다. 예를 들어 GitLab exports the report와 같이 사용될 경우, 매뉴얼태를 대신 사용할 수 있습니다. 예: The report is exported.

고객 관점

GitLab이 만든 것이 아니라고 하면, GitLab이 고객에게 가져다주는 기능과 이점에 초점을 맞춰라.

예를 들어, 다음과 같이 사용하세요:

소스 및 타겟 브랜치에서 코드를 비교하려면 Merge Request을 사용하세요.

대신에 다음과 같은 표현을 사용하지 마세요:

GitLab을 사용하면 코드를 비교할 수 있습니다.
GitLab이 코드 비교 기능을 만드는 능력을 제공했습니다.
Merge Request을 사용하면 코드를 비교할 수 있습니다.

허용하다 및 활성화하다와 같은 단어를 사용하지 마세요. 대신 you를 사용하여 사용자에게 직접 말하는 것을 시도하세요.

신뢰 구축

제품 설명서는 추가적인 영업 또는 마케팅 텍스트 없이 명확하고 간결한 정보 제공에 중점을 둬야 합니다.

쉽게 또는 간단히와 같은 단어를 사용하지 마세요.
“이 기능을 사용하면 시간과 비용을 절약할 수 있습니다”와 같은 마케팅 구절을 사용하지 마세요.

대신에 사실과 실현 가능한 목표에 중점을 두세요. 구체적으로 말하세요. 예를 들어:

이 기능을 사용하면 빌드 시간이 줄어들 수 있습니다.
프로젝트를 생성할 때 이 기능을 사용하여 시간을 절약할 수 있습니다. API가 파일을 생성하고 매뉴얼으로 개입할 필요가 없습니다.

대문자 사용

회사로서 일반적으로 소문자를 선호합니다.

주제 제목

주제 제목에는 문장 케이스를 사용하세요. 예를 들어:

# 변수 사용하여 파이프라인 구성
## 할일 디렉터리 사용하기

UI 텍스트

버튼 레이블 또는 메뉴 항목과 같은 특정 사용자 인터페이스 텍스트를 참조할 때는 사용자 인터페이스에 표시된 대로 대문자를 사용하세요.

사용자 인터페이스 텍스트에 스타일 오류가 있는 경우, 사용자 인터페이스 텍스트를 변경하기 위해 문제를 생성하거나 MR을 만드세요.

기능 이름

기능 이름은 소문자여야 합니다.

그러나 드물게 기능은 타이틀 케이스가 될 수 있습니다. 이러한 예외 사항은 다음과 같습니다:

이러한 예외 사항은 markdownlint에 프로퍼티 이름으로 추가되어 모든 설명서에 일관되게 적용될 수 있습니다.
단어 디렉터리에 추가되어 있기 때문입니다.

위 단어 디렉터리에 없는 경우, GitLab 기술 작성자에게 조언을 구하세요.

기본적으로 Features 페이지 또는 features.yml의 용어 또는 구문의 대문자 사용에는 맞추지 마세요.

기타 용어

다음의 이름을 대문자로 사용하세요:

GitLab 제품 티어. 예를 들어, GitLab Free 및 GitLab Ultimate.
타사 조직, 소프트웨어 및 제품. 예를 들어, Prometheus, Kubernetes, Git, 그리고 The Linux Foundation.
방법 또는 방법론. 예를 들어, 지속적 통합(Continuous Integration), 지속적 배포(Continuous Deployment), 스크럼(Scrum), 그리고 애자일(Agile).

soruce: https://docs.gitlab.com/ee/README.html

숫자

텍스트의 숫자는 0부터 9까지는 영어로 표기하고, 10 이상은 숫자로 쓰세요. 자세한 내용은 Microsoft Style Guide를 참조하십시오.

텍스트

Markdown으로 작성.
새로운 단락을 작성하려면 빈 줄을 넣으세요.
다른 마크업 사이에는 빈 줄을 넣으세요(예: 각 단락 또는 제목 이후 등). 예시:
```
## 제목
  
단락.
  
- 디렉터리 항목 1
- 디렉터리 항목 2
```

행 길이

소스 콘텐츠를 쉽게 읽을 수 있도록 만들려면, 그리고 변경 사항을 쉽게 비교할 수 있도록 하려면, 가능한 경우 이러한 모범 사례를 따르세요.

긴 줄은 대략 100자에서 끊으세요.
각 새로운 문장은 새로운 줄에서 시작하세요.

코멘트

Markdown 내에 코멘트를 삽입하려면, 발행될 때 렌더링되지 않는 표준 HTML 코멘트를 사용하세요. 예시:

<!-- 이것은 렌더링되지 않는 코멘트입니다 -->

강조

GitLab은 세리프 글꼴과 달리 산세리프 글꼴을 사용하며, 기울임꼴 텍스트는 세리프 글꼴에서와 같이 잘 두드러지지 않습니다. 강조를 표시할 때 굵게 표시하세요. 자세한 내용은 Butterick의 실용적인 타이포그래피 가이드의 굵거나 기울임꼴을 참조하십시오.

용어를 처음 소개할 때는 기울임꼴을 사용할 수 있습니다. 그 외에는 굵게 사용하세요.

단어나 텍스트에 굵게 표시하려면 별표 두 개(**)를 사용하세요(**굵게**).
텍스트를 기울임꼴로 하려면 밑줄(_)을 사용하세요(_기울임꼴_).
인용구에는 꺾쇠 괄호(>)를 사용하세요.

구두점

구두점 사용 지침은 다음과 같습니다.

마침표는 문장 끝에 붙이세요. 테이블의 경우에도 마침표를 붙이세요.
세 개 이상의 항목으로 이루어진 디렉터리에서 마지막 and 또는 or 앞에 시리얼(옥스포드) 쉼표를 사용하세요. (‘OxfordComma.yml’에서 테스트됨).

콘텐츠를 공백으로 구분할 때:

문장 사이에는 한 칸을 띄세요(두 칸 이상을 사용하지 마세요). (‘SentenceSpacing.yml’에서 테스트됨).
줄 바꿈 문자를 사용하지 마세요. 표준 공백을 사용하세요. (‘lint-doc.sh’에서 테스트됨).
들여쓰기에 탭 문자를 사용하지 마세요. 스페이스를 사용하세요. 코드 편집기에서 탭 키를 눌렀을 때 탭 대신 스페이스를 출력하도록 구성할 수 있습니다.

다음 구두점 문자를 사용하지 마세요:

; (세미콜론): 대신 두 문장으로 나누세요.
– (엔 대시) 또는 — (엠 대시): 별도의 문장이나 쉼표를 사용하세요.
“ ” ‘ ’: 곡선 따옴표. 직선 따옴표를 사용하세요. (‘NonStandardQuotes.yml’에서 테스트됨).

자리 표시자 텍스트

코드 블록에는 독자가 특정 값으로 텍스트를 바꾸어야 할 때, <와 >을 사용하여 내용을 강조하세요.

예를 들어:

cp <당신의_소스_디렉터리> <당신의_대상_디렉터리>

텍스트 블록에 자리 표시자가 있는 경우, <와 >을 사용하고 자리 표시자를 역따옴표로 감싸세요. 예를 들어:

**<애플리케이션_이름>에 대한 관리자 동의 허용**을 선택하세요.

키보드 명령

키보드 입력을 참조할 때는 HTML <kbd> 태그를 사용하세요. 예를 들어:

명령을 중지하려면 <kbd>Control</kbd>+<kbd>C</kbd>를 누르세요.

문서가 생성될 때 출력은 다음과 같습니다:

명령을 중지하려면 Control+C를 누르세요.

UI의 버튼

가시적인 라벨이 있는 요소에 대해 일치하는 대문자로 된 굵은 글씨를 사용하세요.

예를 들어: **취소**를 선택하세요.

UI에 입력된 텍스트

사용자가 UI에 무언가를 입력해야 할 경우, 역따옴표를 사용하세요. 예를 들어:

**커밋 메시지** 텍스트 상자에 `이것이 내 Merge Request입니다`를 입력하세요.

따옴표보다 역따옴표가 더 명확합니다. 예를 들어, 다음과 같은 문자열:

커밋 메시지 텍스트 상자에 “이것이 내 Merge Request입니다.”를 입력하세요.

이 문자열에서는 사용자가 마침표를 문자열에 포함해야 하는지 여부가 명확하지 않습니다.

인라인 코드

인라인 코드 스타일은 일반 텍스트와 함께 적용됩니다.

인라인 코드 스타일을 사용하세요:

파일 이름 또는 구성 파일의 일부인 경우. 예를 들어, .gitlab-ci.yml, CODEOWNERS, only: [main].
HTTP 메서드(HTTP POST) 및 HTTP 상태 코드, 전체(404 File Not Found) 및 약식(404). 예를 들어, 러너를 삭제하려면 DELETE 요청을 보내세요. 러너를 만들려면 POST 요청을 보내세요.

인라인 코드 스타일을 적용하기 위해 해당 텍스트를 역따옴표로 감싸세요(`). 예를 들어, 이것은 인라인 코드 스타일입니다.

코드 블록

코드 블록 스타일은 코드 텍스트를 일반 텍스트와 분리합니다. 명령 줄 인터페이스에서 실행되는 명령에 대해 코드 블록 스타일을 사용하세요. 코드 블록 스타일은 독자의 터미널 창에 복사해서 붙이기하기 쉽습니다.

코드 블록 스타일을 적용하기 위해 해당 텍스트를 세 개의 역따옴표(3개 `)로 감싸고 구문 강조 힌트를 추가하세요. 예를 들어:

```plaintext
이것은 코드 블록 스타일입니다
```

코드 블록 스타일을 사용할 때:

코드 블록이 세 개의 역따옴표를 포함하는 경우, 해당 코드 블록에 네 개의 역따옴표(4개 `)를 사용하세요. 예를 들어, 코드 블록 스타일을 설명할 때.
코드 블록 위와 아래에 빈 줄을 추가하세요.
구문 강조 힌트는 코드 블록에 필요합니다. 사용 가능한 구문 강조기의 디렉터리은 지원되는 언어 및 렉서 디렉터리을 참조하세요. 사용 가능한 힌트가 없는 경우 plaintext를 사용하세요.

코드 블록에서의 cURL 명령

cURL 명령에 대한 스타일에 대한 자세한 내용은 cURL 명령을 참조하세요.

디렉터리

정보를 문자로 표현할 때 디렉터리을 사용하세요.

모든 디렉터리 항목을 병렬하게 만드세요. 예를 들어, 일부 항목을 명사로 시작하고 다른 항목을 동사로 시작하지 마세요.
문구가 전체 문장이 아닌 경우 마침표를 사용하지 마세요.
모든 항목에 같은 구두점을 사용하세요.
모든 항목을 대문자로 시작하세요.

설명 텍스트를 소개 문구로부터 콜론(:)으로 구분하세요. 예를 들어:

다음을 할 수 있습니다:
  
- 이 일을 할 수 있습니다.
- 다른 일을 할 수 있습니다.

순서가 있는 디렉터리 또는 순서가 없는 디렉터리 중 선택

단계의 순서에 따라 정렬된 디렉터리을 사용하세요. 예를 들어:

무언가를 실행하는 데는 다음 단계를 따르세요.

먼저, 첫 번째 단계를 수행하세요.
다음으로, 다음 단계를 실행하세요.
마지막으로, 마지막 단계를 수행하세요.

단계가 순서대로 수행되지 않아도 되는 경우 순서가 없는 디렉터리을 사용하세요. 예를 들어:

다음 항목이 가져와집니다:

- 항목 1
- 항목 2
- 항목 3

디렉터리 마크업

비순서형 디렉터리에는 별표(*) 대신 대시(-)를 사용합니다.
순서형 디렉터리의 모든 항목은 1.로 시작합니다. 렌더링될 때 디렉터리 항목은 연속적입니다.
디렉터리 앞 뒤에 빈 줄을 남깁니다.
디렉터리 항목 내부에서 Merge된 하위 항목(https://www.example.com#nesting-inside-a-list-item)을 나타내기 위해 줄을 시작하려면 공백(탭이 아님)으로 표시합니다.

디렉터리 항목 안의 중첩

디렉터리 항목 아래에 항목을 중첩시켜 동일한 들여쓰기로 렌더링할 수 있습니다. 이를 위해 다음과 같은 방법을 사용할 수 있습니다:

중첩된 항목은 항상 디렉터리 항목의 첫 문자와 일치해야 합니다. 대시(-)를 사용하는 비순서형 디렉터리의 경우, 들여쓰기 수준마다 두 개의 공백을 사용합니다:

- 비순서형 디렉터리 항목 1
  
  `U`와 일치하도록 2개의 공백을 사용하여 중첩된 줄.

- 비순서형 디렉터리 항목 2
  
  > 디렉터리 항목 2 내부에 중첩될 인용 블록.

- 비순서형 디렉터리 항목 3
  
  ```plaintext
  디렉터리 항목 3 내부에 중첩된 코드 블록
  ```

- 비순서형 디렉터리 항목 4
  
  디렉터리 항목 4 내부에 중첩될 이미지 ![image.png](image.png)

순서형 디렉터리의 경우, 각 들여쓰기 수준마다 세 개의 공백을 사용합니다:

1. 순서형 디렉터리 항목 1
   
   `O`와 일치하도록 3개의 공백을 사용하여 중첩된 줄.

다른 디렉터리 안에 디렉터리을 중첩시킬 수 있습니다.

1. 순서형 디렉터리 항목 하나.
1. 순서형 디렉터리 항목 둘.
   - 중첩된 비순서형 디렉터리 항목 하나.
   - 중첩된 비순서형 디렉터리 항목 둘.
1. 순서형 디렉터리 항목 셋.

- 비순서형 디렉터리 항목 하나.
- 비순서형 디렉터리 항목 둘.
  1. 중첩된 순서형 디렉터리 항목 하나.
  1. 중첩된 순서형 디렉터리 항목 둘.
- 비순서형 디렉터리 항목 셋.

테이블

테이블은 복잡한 정보를 간단하게 설명하기 위해 사용되어야 합니다. 많은 경우 한 가지 간단한 설명이 있는 항목 디렉터리을 설명하는 데 비순서형 디렉터리만으로 충분하지만, 행렬로 가장 잘 설명되는 데이터의 경우 테이블이 가장 좋은 선택입니다.

생성 가이드라인

테이블을 접근할 수 있고 빠르게 살펴볼 수 있도록 하기 위해 테이블에 빈 셀이 없어야 합니다. 그 셀에 그 외 유의미한 값이 없는 경우, N/A를 입력할 수 있습니다.

테이블을 유지 보수하기 쉽도록 열 너비를 일관되게 유지하기 위해 추가 공백을 추가할 수 있습니다. 예를 들어:

  | 앱 이름 | 설명                  | 요구 사항     |
  |--------|----------------------|----------------|
  | 앱 1   | 설명 텍스트 1.       | A, B 및 C     |
  | 앱 2   | 설명 텍스트 2.       | 없음          |

아주 넓은 테이블의 경우 오른쪽 열에서 추가 공백을 생략할 수 있습니다. 예를 들어:

  | 설정     | 기본값 | 설명                                |
  |-----------|--------|--------------------------------------|
  | 설정 1   | `1000` | 간단한 설명.                       |
  | 설정 2   | `2000` | 이 열의 모든 셀이 맞추면 테이블이 너무 넓어지고 너무 많은 공백이 생기기 때문에 너무 넓은 테이블이 됩니다. |
  | 설정 3   | `0`    | 또 다른 간단한 설명.               |

테이블 형식팅을 위한 편집기 확장 기능

모든 Markdown 파일에서 일관된 테이블 형식을 보장하려면 VS Code Markdown Table Formatter로 테이블을 형식화하는 것을 고려하세요. 이 확장의 설정을 위와 같이 구성하려면 헤더 행 길이 따르기 설정을 활성화하세요.

UI에서:
1. VS Code 메뉴에서 코드 > 설정 > 설정으로 이동합니다.
2. 최후 열 길이 제한을 검색합니다.
3. 최후 열 길이 제한 드롭다운 디렉터리에서 헤더 행 길이 따르기를 선택합니다.

VS Code settings.json에서 다음 줄을 추가합니다.

{
  "markdown-table-formatter.limitLastColumnLength": "헤더 행 길이 따르기"
}

이 확장을 사용하여 테이블을 형식화하려면 전체 테이블을 선택하고 마우스 오른쪽 버튼을 클릭한 후 다음으로 형식 지정을 선택하고 VS Code 명령 팔레트에서 Markdown Table Formatter를 선택합니다.

또는 Sublime Text를 사용하는 경우 Markdown Table Formatter 플러그인을 시도해볼 수 있지만 헤더 행 길이 따르기 설정은 없습니다.

기존 테이블의 업데이트

기존 테이블에 행을 추가하거나 편집할 때 새 행의 셀은 더 넓을 수 있습니다. 그럴 경우 너비에 맞게 열을 다시 정렬하면 전체 테이블이 수정된 것으로 표시되어 차이를 읽기 어려워집니다만, docs.gitlab.com에서 테이블은 정상적으로 렌더링됩니다. 기술 문서 팀은 다음 페이지 리팩토링 시에 셀을 다시 정렬할 수 있습니다.

테이블 헤더

테이블 헤더에는 문장 케이스를 사용합니다. 예를 들어, 키워드 값 또는 프로젝트 이름.

기능 테이블

기능 디렉터리 테이블(예: 권한 페이지에서 각 역할에 대한 사용 가능한 기능 디렉터리)을 작성할 때 다음 구호를 사용하세요:

옵션	마크다운	표시 결과
아니오	`{점선 원} 아니오`	{점선 원} 아니오
예	`{체크 원} 예`	{체크 원} 예

API 문서에서 **{점선 원}**와 **{체크 원}**을 사용하지 마세요. 대신 API 주제 템플릿을 따르세요.

각주

테이블 자체에 내용을 포함할 수 없을 때에만 테이블 아래에 각주를 사용하세요. 예를 들어 다음과 같은 경우 각주를 사용하세요:

여러 테이블 셀에 동일한 정보를 제공해야 할 때.
테이블 레이아웃을 방해할 수 있는 콘텐츠를 포함해야 할 때.

각주 형식

테이블 내부에서는 <sup> HTML superscript 태그를 각각의 각주에 사용합니다. 문장 끝에 태그를 넣습니다. 문장과 태그 사이에는 한 칸의 공백을 남깁니다.

예를 들어:

| 앱 이름 | 설명                  |
|:---------|:------------------------|
| 앱 A    | 설명 텍스트. <sup>1</sup> |
| 앱 B    | 설명 텍스트. <sup>2</sup> |

각주 아래에 다음과 같이 **각주:**를 적고 순서가 매겨진 디렉터리을 사용합니다.

예를 들어:

**각주:**

1. 첫 번째 각주입니다.
1. 두 번째 각주입니다.

테이블과 각주는 다음과 같이 렌더링됩니다:

앱 이름	설명
앱 A	설명 텍스트. ¹
앱 B	설명 텍스트. ²

각주:

첫 번째 각주입니다.
두 번째 각주입니다.

다섯 개 이상의 각주

테이블 내부에 포함할 수 없는 다섯 개 이상의 각주가 있는 경우, 연속된 숫자를 사용할 수 있습니다. 연속된 숫자를 사용하는 경우 Markdown rule 029를 비활성화해야 합니다:

**각주:**

<!-- 순차 디렉터리 항목 접두사 비활성화 https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029 - -->
<!-- markdownlint-disable MD029 -->

1. 이것은 첫 번째 각주입니다.
2. 이것은 두 번째 각주입니다.
3. 이것은 세 번째 각주입니다.
4. 이것은 네 번째 각주입니다.
5. 이것은 다섯 번째 각주입니다.

<!-- markdownlint-enable MD029 -->


## 인용구

마크다운 콘텐츠에 대해서만 유효하며, front matter 항목에는 해당되지 않습니다:

- 표준 인용구: 이중 인용부호(`"`). 예: "This is wrapped in double quotes".
- 인용구 내의 인용부호: 이중 인용부호(`"`)로 단일 인용부호(`'`)를 감쌉니다. 예: "This sentence 'quotes' something in a quote".

기타 구두점 규칙에 대해서는 [Pajamas Design System 구두점 섹션](https://design.gitlab.com/content/punctuation/)을 참조하십시오.
이것은 [특정 문서 구두점 규칙](#구두점)에 의해 재정의됩니다.

## 링크

링크는 문서가 [단일 근원의 진실](#문서는-단일-근원의-진실-ssot) 원칙을 준수하는 데 도움이 됩니다.

그러나 한 페이지에 링크를 너무 많이 넣지 않도록 주의하십시오. 링크가 너무 많으면 가독성에 지장을 줄 수 있습니다.

- 같은 페이지에서 링크를 중복해서 걸지 마십시오. 예를 들어 **페이지 A**에서는 **페이지 B**로 여러 번 링크하지 마십시오.
- 단락 하나에 여러 개의 링크를 피하십시오.
- 하나의 단락에서 여러 개의 링크를 피하십시오.
- 한 페이지에서 다른 페이지로 링크를 걸 때, 15개 이상의 링크를 사용하지 않도록 노력하십시오.
- [관련 주제](../topic_types/index.md#related-topics)를 사용하여 작업의 흐름을 방해하는 링크를 줄이는 방법을 고려하십시오.
- 같은 리포지터리 내 다른 페이지에 링크하려면 상대 파일 경로를 사용하십시오. 예를 들어, `../user/gitlab_com/index.md`.
- `[Text](https://example.com)`와 같은 인라인 링크 마크다운 형식을 사용하십시오. 참조형 링크 `[Text][identifier]`보다는 인라인 형식을 사용하십시오.
- linters가 찾을 수 있도록 링크 전체를 하나의 줄에 넣으십시오.

### 별도의 리포지터리 내 링크

다른 리포지터리의 페이지로 링크하려면 절대 URL을 사용하십시오. 예를 들어, GitLab 리포지터리의 페이지에서 Charts 리포지터리로 링크하려면 `https://docs.gitlab.com/charts/`와 같은 URL을 사용하십시오.

### 앵커 링크

각 주제 제목에는 앵커 링크가 있습니다. 예를 들어, "## This is an example"라는 제목을 가진 주제는 `#this-is-an-example` 앵커를 가지고 있습니다.

페이지의 첫 번째 주제 제목( `h1` )에는 앵커 링크가 있지만, 사용하지 마십시오. 대신 페이지에 링크를 하십시오.

Kramdown을 사용하면 HTML 요소에 사용자 정의 ID를 추가할 수 있지만, `/help`에서는 이러한 ID가 작동하지 않으므로 사용하지 마십시오.

주제 제목 텍스트를 변경하면 앵커 링크도 변경됩니다. 깨진 링크를 피하려면 다음을 준수하십시오:

- 주제 제목에 단계 번호를 사용하지 마십시오.
- 가능한 경우 미래에 변경될 수 있는 단어를 사용하지 마십시오.

#### 링크 및 제목 변경

주제 제목을 변경하면 앵커 링크도 변경됩니다. 관련 링크를 업데이트하도록 하기 위해 다음 디렉터리를 검색하십시오:

- `doc/*`
- `app/views/*`
- `ee/app/views/*`

이러한 링크를 수정하지 않으면 Merge Request의 [`ui-docs-lint` 작업](../testing/index.md#tests-in-ui-docs-links-lint)이 실패합니다.

### 링크 텍스트

링크 텍스트에 대한 지침은 다음과 같습니다.

#### 표준 텍스트

가능한 한 다음 중 하나의 패턴을 따르는 텍스트를 사용하십시오:

- `자세한 내용은 [링크 텍스트](링크)를 참조하십시오.`
- `이 작업을 수행하려면 [링크 텍스트](링크)를 참조하십시오.`

예:

- `자세한 내용은 [merge requests](LINK)를 참조하십시오.`
- `리뷰 앱을 생성하려면 [review apps](LINK)를 참조하십시오.`

이 텍스트를 `이 기능에 대한 자세한 내용은...`과 같은 구문을 사용하여 확장할 수 있습니다.

다음과 같은 구성을 사용하지 마십시오:

- `더 알아보기...`
- `자세히 읽으려면...`.
- `자세한 내용은 [Merge Request](LINK) 페이지를 참조하십시오.`
- `자세한 내용은 [Merge Request](LINK) 문서를 참조하십시오.`

#### `here`가 아닌 서술적인 텍스트를 사용

링크에 대해 `here` 또는 `this page`와 같은 단어 대신 서술적인 텍스트를 사용하십시오.

예를 들어 다음과 같이 사용하십시오:

- `자세한 내용은 [이 페이지](LINK)를 참조하십시오.`
- `자세한 내용은 [여기](LINK)를 확인하십시오.`

대신에 다음을 사용하십시오:

- `자세한 내용은 [Merge Request](LINK)를 참조하십시오.`.

#### 이슈에 대한 링크

이슈에 링크할 때, 링크에 이슈 번호를 포함하십시오. 예를 들어:

- `자세한 내용은 [이슈 12345](LINK)를 참조하십시오.`.

파운드 기호(`issue #12345`)를 사용하지 마십시오.

### 외부 문서로의 링크

가능한 경우 외부 문서로의 링크를 피하십시오. 이러한 링크는 쉽게 오래된 링크로 변하고 유지하기 어려울 수 있습니다.

- [링크 부패로 이어집니다](https://en.wikipedia.org/wiki/Link_rot).
- [유지 관리에 문제를 일으킵니다](https://gitlab.com/gitlab-org/gitlab/-/issues/368300).

때로는 링크가 필요할 수 있습니다. 이는 문제 해결 단계를 명확히하거나 내용 중복을 방지하는 데 도움이 될 수 있습니다.
외부 문서는 더 정확하고 더 활발하게 유지될 수 있습니다.

추가하는 각 외부 링크에 대해 고객 이익을 평가하여 유지 관리의 어려움을 고려하십시오.

### 기밀 또는 제한된 접근 권한 링크

다음을 직접적으로 링크하지 마십시오:

- [기밀 이슈](../../../user/project/issues/confidential_issues.md).
- 내부 핸드북 페이지.
- [특정 권한](../../../user/permissions.md)이 필요한 프로젝트 기능을 보기 위해.

이러한 링크는 다음과 같은 사람들에게 실패합니다:

- 충분한 권한이 없는 사람들.
- 자동 링크 확인자.

만약 이러한 링크를 사용해야 한다면:

- 이 링크가 비밀 이슈 또는 내부 핸드북 페이지에만 표시되는 경우, 해당 이슈나 페이지가 GitLab 팀 멤버에게만 표시된다는 것을 언급하십시오.
- 링크가 특정 역할이나 권한이 필요한 경우, 해당 정보를 언급하십시오.
- 링크가 링크 확인자에게 실패하지 않도록 역따옴표에 넣어주십시오.

예시:

```markdown
GitLab 팀 멤버는 다음 비밀 이슈에서 더 많은 정보를 확인할 수 있습니다:
`https://gitlab.com/gitlab-org/gitlab/-/issues/<issue_number>`

GitLab 팀 멤버는 다음 내부 핸드북 페이지에서 더 많은 정보를 확인할 수 있습니다: https://internal.gitlab.com/handbook/<link>

프로젝트에 대한 유지자(Maintainer) 역할을 가진 사용자는 파이프라인 편집기를 사용할 수 있습니다:
`https://gitlab.com/gitlab-org/gitlab/-/ci/editor`

코드의 특정 라인에 대한 링크

특정 파일의 특정 라인에 링크할 때, 브랜치 대신 커밋에 링크하십시오. 코드 라인은 시간이 지남에 따라 변경됩니다. 커밋 링크를 사용하여 사용자가 참조하고 있는 특정 라인으로 유도될 수 있도록 합니다. 프로젝트의 파일을 보는 중에 표시되는 퍼머링크(Permalink) 버튼은 해당 파일의 가장 최근 커밋에 대한 링크를 제공합니다.

이렇게 하십시오: [3번 라인에 대한 링크](https://gitlab.com/gitlab-org/gitlab/-/blob/11f17c56d8b7f0b752562d78a4298a3a95b5ce66/.gitlab/issue_templates/Feature%20proposal.md#L3)
이렇게 하지 마십시오: [3번 라인에 대한 링크](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal.md#L3).

만약 그 링크된 표현식이 추가 커밋으로 인해 라인 번호가 변경되었다면, 여전히 그 쿼리에 대해 파일을 검색할 수 있습니다. 그 경우에는 문서를 업데이트하여 가장 최신 파일 버전으로 링크되도록 보장하십시오.

항상 위치 다음에 동작을 사용하십시오.
- 가시성 드롭다운 디렉터리(위치)에서 공개를 선택하십시오(동작).
간결하고 구체적으로하십시오. 예:
- 이렇게 하십시오: 저장을 선택하십시오.
- 이렇게 하지 마십시오: 변경 사항이 적용되려면 저장을 선택하십시오.
단계에 이유를 포함해야하는 경우, 해당 단계로 시작하십시오. 이렇게하면 사용자가 더 빨리 스캔할 수 있습니다.
- 이렇게 하십시오: 변경 사항을 보려면 Merge Request에서 링크를 선택하십시오.
- 이렇게 하지 마십시오: 변경 사항을 보려면 Merge Request에서 링크를 선택하십시오.

메뉴 이름

메인 GitLab 사용자 인터페이스 요소를 참조할 때 이러한 용어를 사용하십시오.

왼쪽 사이드바: 이것은 사용자 인터페이스 왼쪽에있는 내비게이션 사이드바입니다.
- context switcher 또는 switch contexts와 같은 구문을 사용하지 마십시오. 대신, 사용자를 정확한 위치로 이동하는 일련의 반복 가능한 단계로 안내하십시오.
- 탐색 메뉴 또는 내 작업 사이드바와 같은 구문을 사용하지 마십시오. 대신, 왼쪽 사이드바를 사용하십시오.
오른쪽 사이드바: 이것은 열려 있는 이슈, Merge Request 또는 에픽에 특화된 사용자 인터페이스 오른쪽에있는 내비게이션 사이드바입니다.

UI 요소 이름

버튼 및 확인란과 같은 UI 요소는 굵게 표시되어야 합니다. 개별 UI 요소에 대한 지침은 단어 디렉터리에 있습니다.

탐색 작업 단계 작성 방법

일관성을 유지하려면 탐색 단계를 작성할 때 다음 예제를 사용하십시오.
대안적인 단계가 있을 수 있지만 기본적으로 고정된 항목을 포함하여 다음 단계를 사용하십시오.

프로젝트 설정 열기:

왼쪽 사이드바에서 **검색 또는 이동**을 선택하고 프로젝트를 찾습니다.
**설정 > CI/CD**를 선택합니다.
**일반 파이프라인**을 확장합니다.

그룹 설정 열기:

왼쪽 사이드바에서 **검색 또는 이동**을 선택하고 그룹을 찾습니다.
**설정 > CI/CD**를 선택합니다.
**일반 파이프라인**을 확장합니다.

프로젝트 또는 그룹 설정 열기:

왼쪽 사이드바에서 **검색 또는 이동**을 선택하고 프로젝트 또는 그룹을 찾습니다.
**설정 > CI/CD**를 선택합니다.
**일반 파이프라인**을 확장합니다.

프로젝트 생성하기:

1. 왼쪽 사이드바에서 위쪽에 있는 **새로 만들기** (**{plus}**)를 선택하고 **새 프로젝트/리포지터리**를 선택합니다.

그룹 만들기:

1. 왼쪽 사이드바에서 위쪽에 있는 **새로 만들기** (**{plus}**)를 선택하고 **새 그룹**을 선택합니다.

관리자 영역 열기:

1. 왼쪽 사이드바에서 아래쪽에 있는 **관리자 영역**을 선택합니다.
1. **설정 > CI/CD**를 선택합니다.

두 번째 단계에서 왼쪽 사이드바를 반복해서 언급할 필요가 없습니다.

내 작업 메뉴 항목 선택:

1. 왼쪽 사이드바에서 **검색 또는 이동**을 선택합니다.
1. **내 작업**을 선택합니다.

아바타 선택:

1. 왼쪽 사이드바에서 아바타를 선택합니다.

드롭다운 디렉터리에서 선택 저장하기:

이슈로 이동합니다.
오른쪽 사이드바의 **반복** 섹션에서 **편집**을 선택합니다.
드롭다운 디렉터리에서 이 문제와 관련 지을 반복을 선택합니다.
드롭다운 디렉터리 외부의 어느 영역이나 선택합니다.

모든 프로젝트 보기:

1. 왼쪽 사이드바에서 **검색 또는 이동**을 선택합니다.
1. **내 모든 프로젝트 보기**를 선택합니다.

모든 그룹 보기:

1. 왼쪽 사이드바에서 **검색 또는 이동**을 선택합니다.
1. **내 모든 그룹 보기**를 선택합니다.

선택사항 단계

단계가 선택적 인 경우, 단계 앞에 Optional 단어를 붙입니다.

예:

1. Optional. 작업에 대한 설명을 입력합니다.

권장 단계

단계를 권장하는 경우, 단계 앞에 Recommended 단어를 붙입니다.

예:

1. Recommended. 작업에 대한 설명을 입력합니다.

한 번에 여러 필드 문서화

UI 텍스트가 섹션의 필드를 충분히 설명하는 경우, 각 필드에 대한 작업 단계를 포함하지 마십시오.
대신, 여러 필드를 요약하는 단일 작업 단계에 요약하십시오.

필드를 완료라는 구문을 사용하십시오.

예:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > 리포지터리를 선택합니다.
푸시 규칙을 확장합니다.
필드를 완료합니다.

여러 필드를 문서화하고 하나의 필드만 설명해야하는 경우, 동일한 단계에서 수행하십시오.

푸시 규칙을 확장합니다.
필드를 완료합니다. 브랜치 이름은 정규 표현식이어야합니다.

여러 필드를 설명하기 위해 순서 없는 디렉터리 항목을 사용하십시오:

일반 파이프라인을 확장합니다.
필드를 완료합니다.
- 브랜치 이름은 정규 표현식이어야합니다.
- 사용자는 적어도 Maintainer 역할을 가진 사용자 여야합니다.

삽화

텍스트를 보완하고, 대체하지 않도록 일부적으로만 삽화를 사용하십시오.

삽화는 다음을 이해하는 데 도움이 됩니다:

개념.
복잡한 프로세스에서의 위치.
애플리케이션과 상호 작용해야 하는 방법.

삽화를 산재적으로 사용하십시오.

삽화는 빠르게 구식이 될 수 있습니다.
번역이 어렵고 비용이 많이 듭니다.
콘텐츠는 스크린 리더에서 읽을 수 없습니다.

GitLab 문서에서 사용되는 삽화 유형은 다음과 같습니다:

다이어그램. 프로세스나 엔티티 간의 관계를 설명하는 데 다이어그램을 사용하십시오.
화면 캡처. GitLab 사용자 인터페이스의 일부를 보여줘야 할 때 화면 캡처를 사용하십시오.

가능한 경우 스크린샷 대신 다이어그램을 사용하십시오.

다이어그램 파일의 크기는 일반적으로 스크린샷보다 훨씬 작습니다.
스크린샷은 이미지 품질을 줄이는 일반적인 압축이 필요할 수 있습니다.

다이어그램

프로세스나 엔티티 간의 관계를 설명하기 위해 다이어그램을 사용하십시오.

다이어그램을 만들려면 Mermaid을 사용하십시오.
이 방법은 정적 이미지 형식(스크린샷)보다 여러 장점이 있습니다:

Mermaid 형식은 마크다운 소스에 코드 블록으로 저장되므로 유지 관리하기 쉽습니다.
다이어그램은 동적으로 렌더링되므로 출력 장치 및 크기에 더 적합합니다.
기능 이름과 같은 시간이 지남에 따라 변경할 수 있는 텍스트 콘텐츠를 텍스트 검색 도구로 찾아 편집할 수 있습니다.

다이어그램 생성

다이어그램을 만들려면:

Mermaid Live Editor를 사용하여 다이어그램을 만듭니다.
Code 패널의 내용을 Markdown 파일의 mermaid 코드 블록에 복사합니다. 자세한 내용은 Mermaid를 참조하십시오.
다이어그램의 접근성을 향상시키려면 제목과 설명을 추가하십시오. 다음과 같이 다이어그램 유형(예: flowchart 또는 sequenceDiagram)을 선언한 다음 다음 행에 다음 라인을 추가하십시오:
```
accTitle: 여기에 다이어그램 제목을 입력하십시오
accDescr: 단일 문장으로 다이어그램의 목적을 설명하십시오. 줄 바꿈 없이.
```

Mermaid 다이어그램 문법을 학습하는 것은 어렵습니다. 조금이나마 도움이 되도록 다음을 참조하십시오: Mermaid 입문 가이드 및 Mermaid 사이트의 예제를 참조하십시오.

화면 캡처

GitLab 사용자 인터페이스의 일부를 보여주어야 할 때 화면 캡처를 사용하십시오.

화면 캡처

화면 캡처를 할 때:

가치를 제공하도록 하십시오. lorem ipsum 텍스트를 사용하지 마십시오. 실제 사용 시나리오에서 해당 기능이 어떻게 사용될지를 재현하려고 하고, 실제 텍스트를 사용하려고 하십시오.
관련이 없는 UI를 제외하십시오. 필요하지 않은 공백이나 점을 설명하는 UI 영역을 포함하지 마십시오. GitLab의 사이드바는 변경될 수 있으므로 스크린샷에 불필요하게 포함하지 마십시오. 가능한 한 브라우저 창의 크기를 최소화하여 요소를 가깝게 유지하고 빈 공간을 최소화하십시오. 스크린샷 크기를 최소한으로 유지하십시오.
페이지에서 이미지 미리보기하십시오. 지역적으로 이미지를 렌더링하여 이미지가 흐릿하거나 압도적이지 않은지 확인하십시오.
일관성을 유지하십시오. 일관된 사용자 경험을 위해 문서 페이지에 이미지에 맞는 스크린샷을 사용하십시오. 네비게이션 테마는 Indigo 이고 구문 강조 테마는 라이트이어야 합니다. 이것들은 기본 설정입니다.

콜아웃 추가

스크린샷에서 특정 영역을 강조해야 하는 경우 화살표를 사용하세요.

색상은 #EE2604를 사용하세요. macOS의 미리보기 애플리케이션을 사용하는 경우, 이 색이 기본적으로 빨간색입니다.
선 두께는 3pt를 사용하세요. macOS의 미리보기 애플리케이션을 사용하는 경우, 이것은 디렉터리에서 세 번째 선입니다.
다음 이미지에 표시된 화살표 스타일을 사용하세요.
여러 화살표가 있는 경우 가능한 경우 병렬하게 만드세요.

이미지 저장

필요한 경우 넓거나 긴 스크린샷의 크기를 조정하세요. 그러나 크기를 조정하고 압축한 후에도 스크린샷이 여전히 선명해야 합니다.
모든 이미지는 100KB 이하로 압축되어야 합니다. 많은 경우, 이미지 품질을 줄이지 않고 25-50KB 이하로 압축하는 것이 가능합니다.
GitLab 인터페이스의 이미지인 경우, 파일 이름 뒤에 GitLab 버전을 기준으로 추가하세요. 예를 들어, GitLab 11.1의 파이프라인 페이지에서 캡처한 스크린샷의 유효한 이름은 pipelines_v11_1.png입니다.
사용자 인터페이스 부분을 포함하지 않는 설명을 추가하는 경우, 해당 이미지가 추가된 릴리즈 번호를 뒤에 붙이세요. 예를 들어, 11.1의 마일스톤에 추가된 MR의 경우, 설명에 대한 유효한 이름은 devops_diagram_v11_1.png입니다.
이미지를 작업 중인 .md 문서와 동일한 디렉터리에 있는 img/라는 별도의 디렉터리에 저장하세요.
JPEG 대신 PNG 이미지를 사용하세요.
GIF는 https://ezgif.com/optimize 또는 유사한 도구로 압축하세요.
또한 문서를 설명하기 위해 비디오를 링크하고 임베드하는 방법을 참조하세요.

이미지 압축

문서에 추가하는 모든 새 이미지를 항상 압축해야 합니다. 알려진 도구 중 하나는 pngquant인데, 이는 크로스 플랫폼이고 오픈 소스입니다. 공식 웹사이트를 방문하여 해당하는 OS에 대한 지침을 따라 설치하세요.

macOS를 사용하고 모든 스크린샷을 자동으로 압축하려면 스크린샷 크기를 80%로 만드는 간단한 트릭 하나를 참조하세요.

GitLab에는 매뉴얼 프로세스를 간단화하는 Ruby 스크립트가 있습니다. 로컬 https://gitlab.com/gitlab-org/gitlab 복사본의 루트 디렉터리에서 터미널에서 다음을 실행하세요:

압축하기 전에, 모든 문서 PNG 이미지가 압축되었는지 확인하려면:
```
bin/pngquant lint
```
pngquant를 사용하여 모든 문서 PNG 이미지를 압축하세요:
```
bin/pngquant compress
```

특정 파일 압축:

bin/pngquant compress doc/user/img/award_emoji_select.png doc/user/img/markdown_logo.png

특정 디렉터리의 모든 PNG 파일을 압축하세요:
```
bin/pngquant compress doc/user/img
```

애니메이션 이미지

애니메이션 이미지(예: GIF)를 사용하지 않도록 하세요. 사용자에게 혼란을 줄 수 있습니다.

사용자 인터페이스의 복잡한 상호작용을 설명하고 독자가 이해하는 데 도움이 되는 시각적 표현을 포함하고자 하는 경우 다음을 수행할 수 있습니다:

정적 이미지(스크린샷)를 사용하고 필요한 경우 어떤 영역을 강조하기 위해 콜아웃을 추가하세요.
상호작용의 짧은 비디오를 만들고 링크하세요.

콘텐츠에 이미지 링크 추가

문서에 이미지를 포함시키기 위한 Markdown 코드는 다음과 같습니다: ![이미지 설명, alt 태그로 사용](img/document_image_title_vX_Y.png)

이미지 설명은 문서 사이트에서 렌더링된 이미지의 대체 텍스트입니다. 접근성과 SEO를 위해 정확하고 간결하며 고유한 설명을 사용하세요.

image of 또는 graphic of를 이미지 설명으로 사용하지 마세요.

자동 스크린샷 생성기

자동 스크린샷 생성기를 사용하여 스크린샷을 찍고 압축할 수 있습니다.

GitLab Development Kit (GDK)를 설정하세요.
클론한 GitLab 리포지터리의 하위 디렉터리, 일반적으로 gdk/gitlab,로 이동하세요.
GDK 데이터베이스가 완전히 마이그레이션되었는지 확인하세요: bin/rake db:migrate RAILS_ENV=development.
pngquant을 설치하세요. 도구 웹사이트에서 자세한 정보를 확인하세요: pngquant.
scripts/docs_screenshots.rb spec/docs_screenshots/<name_of_screenshot_generator>.rb <milestone-version>를 실행하세요.
스크린샷의 위치를 식별하세요. 이는 it 매개변수에 정의된 gitlab/doc 위치를 기반으로 합니다.
새롭게 생성된 스크린샷을 커밋하세요.

도구 확장

추가적인 스크린샷 생성기를 추가하려면 다음을 수행하세요:

spec/docs_screenshots 디렉터리에 _docs.rb 확장자를 가진 새 파일을 추가하세요.

파일에 다음 정보를 추가하세요:

require 'spec_helper'
   
RSpec.describe '<스크린샷을 찍는 대상>', :js do
  include DocsScreenshotHelpers # 스크린샷 찍는 메커니즘을 활성화하는 도우미
     
  before do
    page.driver.browser.manage.window.resize_to(1366, 1024) # 페이지의 길이와 너비
  end

각 it 블록에 스크린샷이 저장된 경로를 추가하세요:
```
it '<path/to/images/directory>'
```

visit <path>를 사용하여 페이지의 스크린샷을 찍을 수 있습니다. 공백 스크린샷을 피하기 위해 콘텐츠가 로드될 때까지 기다리기 위해 expect를 사용하세요.

단일 요소 스크린샷

단일 요소의 스크린샷을 찍을 수 있습니다.

스크린샷 생성기 파일에 다음을 추가하세요:

screenshot_area = find('<element>') # 요소 찾기
scroll_to screenshot_area # 요소로 스크롤
expect(screenshot_area).to have_content '<content>' # 캡처하려는 콘텐츠를 기다림
set_crop_data(screenshot_area, <padding>) # 패딩을 추가하여 요소 캡처

spec/docs_screenshots/container_registry_docs.rb를 참고하여 자신의 스크린샷 스크립트를 만드세요.

이모지

어떤 목적으로든 Markdown 이모지 형식인 예를 들어 :smile:를 사용하지 마세요. 대신에 GitLab SVG 아이콘을 사용하세요.

Markdown에서 이모지 사용은 GitLab Flavored Markdown을 필요로 하며, GitLab 문서에 사용된 Markdown 렌더링 엔진인 Kramdown에서는 지원되지 않습니다.

GitLab SVG 아이콘

문서에서 GitLab SVG 라이브러리의 아이콘을 직접 사용할 수 있습니다. 예를 들어, **{tanuki}**는 다음과 같이 렌더링됩니다: .

대개 텍스트에서 아이콘을 사용하는 것을 피해야 하지만, 가용성을 개선하기 위해 대화형 텍스트만 사용하는 경우 아이콘을 사용할 수 있습니다. 예를 들어, 삭제나 편집 버튼은 종종 대화형 텍스트만 가지고 있습니다.

아이콘을 사용할 때, 먼저 호버 텍스트를 사용하고 괄호 안에 SVG 참조를 따르세요.

피하세요: 선택 **{pencil}** **편집**.. 이는 다음과 같이 생성됩니다: 선택 편집.
대신 사용: 선택 **편집** (**{pencil}**). 이는 다음과 같이 생성됩니다: 선택 편집 ().

아이콘을 설명하기 위해 단어를 사용하지 마세요:

피하세요: 선택 **{ellipsis_v}** (휴지통 아이콘).
대신 사용: 선택 **휴지통** (**{remove}**). 이는 다음과 같이 생성됩니다: 선택 휴지통 ().

버튼에 호버 텍스트가 없는 경우, 아이콘을 설명할 수 있습니다. 그 후에 대화형성을 개선하기 위해 UX 버그 이슈를 만드세요.

피하세요: 선택 **{ellipsis_v}**.
대신 사용: 수직 탐색기를 선택합니다 (**{ellipsis_v}**). 이는 다음과 같이 생성됩니다: 수직 탐색기를 선택합니다 ().

비디오

GitLab의 YouTube 비디오 자습서를 문서에 추가하는 것은 매우 장려됩니다. 비디오가 오래되었을 때를 제외하고, 비디오는 문서를 대체하지 않아야 하며 보완 또는 설명하는 데 사용되어야 합니다. 비디오의 내용이 기능과 해당 주요 사용 사례에 매우 중요하지만 문서에 적절하게 다루어지지 않은 경우 다음을 수행해야 합니다.

이 세부 정보를 문서 텍스트에 추가합니다.
비디오를 검토하고 페이지를 업데이트할 수 있도록 이슈를 작성합니다.

제품 리포지터리에는 비디오를 업로드하지 마십시오. 대신 링크 또는 임베드를 사용하십시오.

비디오 링크

비디오를 링크하려면 YouTube 아이콘을 포함하여 독자가 읽기 전에 페이지를 스캔할 수 있도록 해야 합니다. 링크 뒤에 비디오의 게시 날짜를 포함하여 비디오가 오래되었을 수 있는지 확인하는 데 도움이 됩니다.

<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
개요는 [비디오 제목](link-to-video)를 참조하세요.
<!-- 비디오는 YYYY-MM-DD에 게시됨 -->

GitLab 사용자에게 유용한 최신 비디오를 링크할 수 있습니다.

비디오 임베드

GitLab documentation site은 임베드된 비디오를 지원합니다.

the official YouTube account for GitLab에서만 비디오를 임베드할 수 있습니다. 다른 소스의 비디오는 링크해야 합니다.

대부분의 경우 비디오에 링크를 걸어야 합니다. 임베드된 비디오는 페이지에서 많은 공간을 차지하고 독자들에게 주의를 집중시킬 수 있기 때문입니다.

비디오를 임베드하려면:

이 절차에서 코드를 복사하여 Markdown 파일에 붙여넣으십시오. 위와 아래에 빈 줄을 남기십시오. 코드를 수정하지 마십시오(공백을 제거하거나 추가하지 마십시오).
YouTube에서 표시할 비디오 URL을 방문하십시오. 브라우저에서 정규 URL(https://www.youtube.com/watch?v=VIDEO-ID)을 복사하여 <div class="video-fallback"> 아래의 비디오 제목과 링크를 교체하십시오.
YouTube에서 공유을 선택한 다음 임베드를 선택하십시오.
<iframe> 소스(src)(https://www.youtube-nocookie.com/embed/VIDEO-ID)를 복사하여 iframe 태그의 src 필드의 내용을 교체하십시오.
비디오 게시 날짜를 링크 아래에 포함하여 옛날 것일 수 있는 비디오를 확인하기 위해 도와주십시오.

여기에 빈 줄을 남기십시오
<div class="video-fallback">
  비디오를 참조하세요: <a href="https://www.youtube.com/watch?v=MqL6BMOySIQ">비디오 제목</a>.
</div>
<figure class="video-container">
  <iframe src="https://www.youtube-nocookie.com/embed/MqL6BMOySIQ" frameborder="0" allowfullscreen> </iframe>
</figure>
<!-- 비디오는 YYYY-MM-DD에 게시됨 -->
여기에 빈 줄을 남기십시오

GitLab documentation site에서는 다음과 같이 렌더링됩니다.

비디오를 참조하세요: GitLab은 무엇인가요.

이 형식에 따라:

figure 태그는 시맨틱 SEO를 위해 필요하며, video-container 클래스는 동영상이 반응형으로 표시되고 다양한 모바일 장치에 표시되도록 해야 합니다.
<div class="video-fallback">은 GitLab Markdown 프로세서가 iframe을 지원하지 않기 때문에 /help에 필요한 대체물입니다. 이것은 문서 사이트에서 숨겨져 있지만 /help에서 표시됩니다.
www.youtube-nocookie.com 도메인은 YouTube 임베드 플레이어의 개인 정보 보호 모드를 활성화합니다. 이 모드는 제한된 쿠키 환경 설정을 가진 사용자가 임베드된 비디오를 보는 데 도움을 줍니다.

클릭 스루 데모에 대한 링크

클릭 스루 데모에 대한 링크는 비디오와 유사한 지침을 따라야 합니다.

클릭 스루 데모를 보려면 [데모 제목](link-to-demo)를 참조하세요.
<!-- 데모는 YYYY-MM-DD에 게시됨 -->

알림 상자

정보에 주의를 불러일으키기 위해 알림 상자를 사용합니다. 알림 상자를 삼가고, 다른 알림 상자 바로 뒤에 오지 않도록 주의하십시오.

알림 상자는 다음 중 하나의 단어 다음에 줄 바꿈이 되면 생성됩니다:

FLAG:
NOTE:
WARNING:
INFO: (마케팅 전용)
DISCLAIMER:
DETAILS:

예를 들어:

NOTE:
이것은 주목해야 할 사항입니다.

여러 단락, 디렉터리 또는 제목에 대한 알림 상자를 표시하려면, blockquotes를 대신 사용하십시오.

알림 상자는 GitLab documentation site (https://docs.gitlab.com)에서만 렌더링됩니다. GitLab 제품 도움말에서는 알림 상자가 일반 텍스트로 표시됩니다.

Flag

기능의 가용성을 설명하기 위해 이 알림 유형을 사용합니다. FLAG 알림을 형식화하는 방법에 대한 정보는 피처 플래그 뒤에 배포된 기능을 문서화를 참조하십시오.

Note

노트는 되도록이면 삼가야 합니다. 너무 많은 노트는 주제를 스캔하기 어렵게 만들 수 있습니다.

노트를 추가하는 대신:

단락의 일부로 문장을 다시 작성하십시오.
새로운 단락으로 정보를 배치하십시오.
정보를 새로운 주제 제목 아래에 배치하십시오.

노트를 사용해야 하는 경우 다음 형식을 사용하십시오:

NOTE:
주목할 사항입니다.

GitLab documentation site에서 다음과 같이 렌더링됩니다:

주목할 사항입니다.

Warning

경고는 폐기된 기능을 나타내거나 데이터 손실 가능성에 대한 경고를 제공하는 데 사용합니다.

WARNING:
경고해야 할 사항입니다.

GitLab documentation site에서 다음과 같이 렌더링됩니다:

경고해야 할 사항입니다.

Info

마케팅 팀은 INFO 알림을 사용하여 영업 및 마케팅 노력과 관련된 정보를 추가합니다.

INFO: 알림의 텍스트는 항상 주변 텍스트의 오른쪽에 부드럽게 나타납니다. GitLab 문서 사이트를 보려면 MR의 검토 앱을 확인하십시오. 주위 텍스트에서 부유 상자가 나타나길 원하는 위치에 따라 텍스트를 올리거나 내리기도 해야 할 수 있습니다.

예를 들어, 페이지에 다음과 같은 텍스트가 있는 경우:

이것은 소개 단락입니다. GitLab은 Git과 안전하게 통신하기 위해 SSH 프로토콜을 사용합니다.
당신이 SSH 키를 사용하여 GitLab 원격 서버에 인증할 때,
매번 사용자 이름과 암호를 제공할 필요가 없습니다.

INFO:
이것은 일부 정보입니다. 이 정보는 GitLab 작업과 관련하여 중요한 추가 사항이며
이를 고려하고 싶을 수도 있습니다.

그리고 또 다른 단락입니다. GitLab은 Git과 안전하게 통신하기 위해 SSH 프로토콜을 사용합니다.
당신이 SSH 키를 사용하여 GitLab 원격 서버에 인증할 때,
매번 사용자 이름과 암호를 제공할 필요가 없습니다.

그리고 또 다른 단락입니다. GitLab은 Git과 안전하게 통신하기 위해 SSH 프로토콜을 사용합니다.
당신이 SSH 키를 사용하여 GitLab 원격 서버에 인증할 때,
매번 사용자 이름과 암호를 제공할 필요가 없습니다.

GitLab documentation site에서 다음과 같이 렌더링됩니다:

이것은 소개 단락입니다. GitLab은 Git과 안전하게 통신하기 위해 SSH 프로토콜을 사용합니다. 당신이 SSH 키를 사용하여 GitLab 원격 서버에 인증할 때, 매번 사용자 이름과 암호를 제공할 필요가 없습니다.

이것은 일부 정보입니다. 이 정보는 GitLab 작업과 관련하여 중요한 추가 사항이며 이를 고려하고 싶을 수도 있습니다.

그리고 또 다른 단락입니다. GitLab은 Git과 안전하게 통신하기 위해 SSH 프로토콜을 사용합니다. 당신이 SSH 키를 사용하여 GitLab 원격 서버에 인증할 때, 매번 사용자 이름과 암호를 제공할 필요가 없습니다.

고지

미래의 기능을 설명하는 데 사용됩니다. 자세한 정보는 미래 기능에 대한 법적 고지를 참조하십시오.

세부 정보

DETAILS: 경고 상자는 티어 뱃지에 사용됩니다.

인용 구역

인용된 텍스트를 강조 표시하려면 다음 형식을 사용하세요.

> This is a blockquote.

GitLab 문서 사이트에는 다음과 같이 렌더링됩니다.

This is a blockquote.

텍스트가 여러 줄에 걸쳐 있는 경우 이를 분할할 수 있습니다.

여러 단락을 위해 각 줄 앞에 기호 >를 사용하십시오.

> This is the first paragraph.
>
> This is the second paragraph.
>
> - This is a list item
> - Second item in the list

GitLab 문서 사이트에는 다음과 같이 렌더링됩니다.

This is the first paragraph.
This is the second paragraph.

This is a list item
Second item in the list

탭

문서 사이트에서 텍스트를 탭으로 표시할 수 있습니다.

일련의 탭을 만들려면 다음 예제를 따르세요.

::Tabs

:::TabTitle Tab One

Tab One의 콘텐츠가 여기에 있습니다.

:::TabTitle Tab Two

Tab Two의 다른 콘텐츠가 여기에 있습니다.

::EndTabs

위 코드는 GitLab 문서 사이트에서 다음과 같이 렌더링됩니다.

Tab One

Tab One의 콘텐츠가 여기에 있습니다.

Tab Two

Tab Two의 다른 콘텐츠가 여기에 있습니다.

탭 제목은 간결하고 일관성 있게 작성해야 합니다. 병렬이 되도록하고 각 탭은 대문자로 시작되어야 합니다. 예시:

Linux 패키지 (Omnibus), Helm 차트 (Kubernetes) (구성 편집에 대한 문서 작성 시에는 구성 편집 가이드를 따르세요.)
15.1 이전, 15.2 이후

우리가 탭에 대한 링크가 망가진 링크에 대해 자동화된 테스트를 구현할 때까지 (이슈 1355), 유니크한 URL 매개변수를 가지고 있더라도 한 개의 탭에 직접적으로 링크하지 마십시오.

자세한 내용은 Pajamas를 참조하십시오.

표절

다른 출처에서의 내용을 제한된 인용과 출처를 표기한 경우를 제외하고는 다른 출처에서 내용을 복사하여 붙여넣지 마십시오. 관련 정보를 여러분의 말로 다시 표현하거나 다른 출처로 연결하는 것이 더 좋습니다.

제품 및 기능

GitLab 제품 문서에서 제품과 기능을 설명할 때 이 섹션의 정보를 참조하십시오.

이름에 줄 바꿈 피하기

기능이나 제품 이름에 공백이 포함된 경우 이름을 줄 바꿈하여 분할하지 마십시오. 이름이 변경되면 줄 바꿈된 텍스트를 검색하거나 grep하는 것이 더 복잡해집니다.

제품 티어 뱃지

티어 뱃지는 기능에 대한 정보를 제공하며 주제 제목 아래에 표시됩니다.

티어 뱃지를 추가해야 하는 경우

다음 위치에 티어 뱃지를 할당하십시오.

doc/development/* 및 doc/solutions/* 아래의 페이지를 제외한 대부분의 H1 주제 제목.
H1과 동일한 티어가 적용되지 않는 주제 제목.

H1 티어 뱃지는 페이지에 있는 기능의 가장 낮은 티어에 해당하는 뱃지여야 합니다.

티어 뱃지를 추가하지 말아야 하는 경우

티어 뱃지를 할당하지 마십시오:

기능이 하나의 명백한 구독 티어나 오퍼링을 갖지 않는 경우. 예를 들어, 기능이 SaaS에는 한 티어에 적용되고 Self-Managed에는 다른 티어에 적용되는 경우.

이 경우 다음 중 하나 이상을 수행하십시오:

경고 상자의 NOTE를 사용하여 티어에 대한 설명을 작성하십시오.
이 정보가 더 많은 의미를 가질 수 있는 다른 주제 제목 아래에 티어 뱃지를 추가하십시오.
H1 아래에 티어 뱃지를 추가하지 마십시오.

티어 뱃지가 필요하지 않은 페이지

어떤 페이지에서는 명확한 티어 뱃지가 적용되지 않기 때문에 해당 페이지에는 티어 뱃지가 없을 수 있습니다. 예를 들어:

튜토리얼.
다른 티어의 기능을 비교하는 페이지.
/development 폴더 내의 페이지. 이러한 페이지에는 자동으로 Contribute 뱃지가 할당됩니다.
/solutions 폴더 내의 페이지. 이러한 페이지에는 자동으로 Solutions 뱃지가 할당됩니다.

사용 가능한 제품 티어 뱃지

티어 뱃지는 주제 제목 아래에 표시되는 정보를 가리킵니다.

티어 뱃지에는 티어, 오퍼링, 상태, 히스토리가 포함됩니다.

티어 뱃지의 마크다운 형식은 다음과 같아야 합니다.

# Topic title

DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-Managed, GitLab Dedicated
**Status:** Experiment

> - GitLab 16.3에서 [도입됨](<link-to-issue>).
> - GitLab 16.4에서 업데이트됨.

오퍼링의 경우 다음 단어들의 조합 중 하나를 쉼표로 구분하여 사용하십시오.

GitLab.com
Self-Managed
GitLab Dedicated

예를 들어:

GitLab.com
GitLab.com, Self-Managed
Self-Managed
Self-Managed, GitLab Dedicated

티어의 경우 다음 중 하나를 선택하십시오.

Free, Premium, Ultimate
Premium, Ultimate
Ultimate

상태의 경우 다음 중 하나를 선택하십시오.

Beta
Experiment

보통 사용 가능한 기능에는 상태가 포함되어서는 안됩니다.

GitLab Duo Pro 추가 옵션

이 추가 옵션은 다른 구독 티어와 함께 속합니다. with GitLab Duo Pro 구문을 사용하여 이를 문서화하십시오. 예를 들어:

**Tier:** Premium or Ultimate with GitLab Duo Pro

하위 제목에서의 티어, 오퍼링, 또는 상태 중복

하위 제목이 상위 주제와 동일한 티어, 오퍼링, 또는 상태를 가질 경우 해당 정보를 하위 제목의 뱃지에 반복해서 표시할 필요가 없습니다.

예를 들어, 제목 1이 다음과 같은 경우:

# My title

DETAILS:
**Offering:** GitLab.com
**Tier:** Premium, Ultimate

동일한 오퍼링을 가지지만 다른 티어에 속하는 하위 레벨 제목은 다음과 같을 것입니다:

## My title

DETAILS:
**Tier:** Ultimate

인라인 티어 뱃지

다른 텍스트와 함께 티어 뱃지를 인라인으로 추가하지 마십시오. 기능의 유일한 제공처는 해당 기능이 설명된 주제여야 합니다.

인라인으로 티어를 언급해야 하는 경우 해당 내용을 일반 텍스트로 작성하십시오. 예를 들어, API 주제의 경우 다음과 같습니다.

이슈를 할당할 사용자의 ID. Ultimate 전용.

더 많은 예시는 REST API style guide를 참조하십시오.

관리자 문서에서의 티어 뱃지

인스턴스 관리자만을 위한 주제는 Self-Managed 티어를 가져야 합니다. 인스턴스 관리자 문서에는 종종 다음을 언급하는 섹션이 포함됩니다:

gitlab.rb 또는 gitlab.yml 파일의 변경.
Rails 콘솔 액세스 또는 Rake 작업 실행.
관리 영역에서의 작업 수행.

이러한 페이지는 해당 작업이 인스턴스 관리자만 수행할 수 있는 것임을 언급해야 합니다.

특정 섹션

특정 섹션에는 특정 스타일을 적용해야 합니다. 특정 섹션에 대한 스타일은 이 섹션에서 설명합니다.

도움말 및 피드백 섹션

이 섹션은 각 문서의 끝에 표시되며, front matter에 키를 추가하여 이를 생략할 수 있습니다.

---
feedback: false
---

기본값은 이 섹션을 그대로 둡니다. 문서에서 이를 생략하려면 꼭 기술 적 작성자와 상의하십시오.

피드백 섹션의 클릭 이벤트는 Google Tag Manager로 추적됩니다. 변환은 Google Analytics에서 Behavior > Events > Top events > docs로 이동하여 볼 수 있습니다.

GitLab 재시작

GitLab의 재시작 또는 재구성이 필요한 경우 ‘reconfigure’를 필요에 맞춰 ‘restart’로 대체하여 다음과 같이 doc/administration/restart_gitlab.md에 링크될 수 있도록 중복을 피하십시오.

파일을 저장하고 변경 사항이 적용되려면 [GitLab 재구성](../../../administration/restart_gitlab.md)하십시오.

doc/ 디렉터리 외부에 문서가 있는 경우 상대적 링크 대신 전체 경로를 사용하십시오: https://docs.gitlab.com/ee/administration/restart_gitlab.html.

다양한 설치 방법 문서화 방법

GitLab은 다섯 가지 공식 설치 방법을 지원합니다. 문장 및 제목의 일부로 단어를 참조하는 경우 다음 구문을 사용하세요.

Linux package
Helm chart
GitLab Operator
Docker
Self-compiled

설명에 괄호를 추가해도 괜찮습니다. 탭 사용:

Linux package (Omnibus)
Helm chart (Kubernetes)
GitLab Operator (Kubernetes)
Docker
Self-compiled (source)

탭을 사용하여 Self-Managed형 구성 절차 설명

구성 절차는 사용자가 구성 파일을 편집하거나 GitLab을 다시 구성하거나 GitLab을 다시 시작해야 할 수 있습니다. 이 경우:

다양한 설치 방법을 구분하기 위해 탭을 사용하세요.
이전 디렉터리에 설명된 것과 정확히 동일한 설치 방법 이름을 사용하세요.
아래에 설명된 순서대로 사용하세요.
코드 블록을 해당 디렉터리 항목과 일치하도록 들여쓰기하세요.
각 코드 블록에 적절한 구문 강조 표시를 사용하세요(ruby, shell, 또는 yaml).
YAML 파일의 경우 항상 상위 설정을 포함하세요.
GitLab을 다시 구성하거나 다시 시작하는 마지막 단계는 항상 동일하므로 구체적으로 사용할 수 있습니다.

구성 편집을 설명할 때, 다음 스니펫을 사용하고 수정할 수 있습니다:

::Tabs

:::TabTitle Linux package (Omnibus)

1. `/etc/gitlab/gitlab.rb` 편집:
   
   ```ruby
   external_url "https://gitlab.example.com"
   ```

1. 파일 저장 및 GitLab 다시 구성:
   
   ```shell
   sudo gitlab-ctl reconfigure
   ```

:::TabTitle Helm chart (Kubernetes)

1. Helm 값 내보내기:
   
   ```shell
   helm get values gitlab > gitlab_values.yaml
   ```

1. `gitlab_values.yaml` 편집:
   
   ```yaml
   global:
     hosts:
       gitlab:
         name: gitlab.example.com
   ```

1. 파일 저장 및 새 값 적용:
   
   ```shell
   helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
   ```

:::TabTitle Docker

1. `docker-compose.yml` 편집:
   
   ```yaml
   version: "3.6"
   services:
     gitlab:
       environment:
         GITLAB_OMNIBUS_CONFIG: |
           external_url "https://gitlab.example.com"
   ```

1. 파일 저장 및 GitLab 재시작:
   
   ```shell
   docker compose up -d
   ```

:::TabTitle Self-compiled (source)

1. `/home/git/gitlab/config/gitlab.yml` 편집:
   
   ```yaml
   production: &base
     gitlab:
       host: "gitlab.example.com"
   ```

1. 파일 저장 및 GitLab 재시작:
   
   ```shell
   # systemd를 실행 중인 시스템의 경우
   sudo systemctl restart gitlab.target
   
   # SysV init를 실행 중인 시스템의 경우
   sudo service gitlab restart
   ```

::EndTabs

렌더링 결과는 다음과 같습니다:

Linux package (Omnibus)

/etc/gitlab/gitlab.rb 편집:

external_url "https://gitlab.example.com"

파일 저장 및 GitLab 다시 구성:
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

Helm 값 내보내기:

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml 편집:

global:
  hosts:
    gitlab:
      name: gitlab.example.com

파일 저장 및 새 값 적용:

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

Docker

docker-compose.yml 편집:

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url "https://gitlab.example.com"

파일 저장 및 GitLab 재시작:
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml 편집:

production: &base
  gitlab:
    host: "gitlab.example.com"

파일 저장 및 GitLab 재시작:

# systemd를 실행 중인 시스템의 경우
sudo systemctl restart gitlab.target
   
# SysV init를 실행 중인 시스템의 경우
sudo service gitlab restart

버전 업그레이드를 위한 변경 사항

GitLab의 각 주요 버전마다 새 페이지를 만들어 업그레이드 노트와 변경 사항을 문서화하세요. 예시를 보시려면 GitLab 16 변경 사항을 참조하세요. 페이지에 정보를 추가하기 위해 다음 템플릿을 사용하세요.

# GitLab X 변경 사항

DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-Managed, GitLab Dedicated

이 페이지에는 GitLab X의 마이너 및 패치 버전에 대한 업그레이드 정보가 포함되어 있습니다. 다음을 위해 이러한 지침을 검토하세요:

- 귀하의 설치 유형.
- 현재 버전과 대상 버전 사이의 모든 버전.

GitLab Helm Chart를 업그레이드하는 자세한 정보는 [X.0 릴리스 노트](https://docs.gitlab.com/charts/releases/X_0.html)를 참조하세요.

## X.Y.1 (페이지 상단에 최신 버전 추가)

- 일반적인 업그레이드 노트 및 이슈.
- ...

### Linux package 설치

- Linux package 설치에 특정한 정보.
- ...

### Self-compiled 설치

- Self-compiled 설치에 특정한 정보.
- ...

### Geo 설치

DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-Managed
 
 - Geo 설치에 특정한 정보.
 - ...

## X.Y.0
 
 ...

문서 스타일 가이드

GitLab 음성

문서는 참중이라는 싱글 소스입니다(SSoT)

주제 유형

문서 우선 방법

로컬라이제이션을 위한 작성

Markdown

Markdown에서의 HTML

Markdown에서의 제목 레벨

Markdown에서의 역따옴표

언어

능동태

고객 관점

신뢰 구축

대문자 사용

주제 제목

UI 텍스트

기능 이름

기타 용어

숫자

텍스트

행 길이

코멘트

강조

구두점

자리 표시자 텍스트

키보드 명령

UI의 버튼

UI에 입력된 텍스트

인라인 코드

코드 블록

코드 블록에서의 cURL 명령

디렉터리

순서가 있는 디렉터리 또는 순서가 없는 디렉터리 중 선택

디렉터리 마크업

디렉터리 항목 안의 중첩

테이블

생성 가이드라인

테이블 형식팅을 위한 편집기 확장 기능

기존 테이블의 업데이트

테이블 헤더

기능 테이블

각주

각주 형식

다섯 개 이상의 각주

코드의 특정 라인에 대한 링크

내비게이션

메뉴 이름

UI 요소 이름

탐색 작업 단계 작성 방법

선택사항 단계

권장 단계

한 번에 여러 필드 문서화

삽화

다이어그램

다이어그램 생성

화면 캡처

화면 캡처

콜아웃 추가

이미지 저장

이미지 압축

애니메이션 이미지

콘텐츠에 이미지 링크 추가

자동 스크린샷 생성기

도구 확장

단일 요소 스크린샷

이모지

GitLab SVG 아이콘

비디오

비디오 링크

비디오 임베드

클릭 스루 데모에 대한 링크

알림 상자

Flag

Note

Warning

Info

고지

세부 정보

인용 구역