GitLab의 음성
문서는 단일 정보 원천입니다 (SSoT)
주제 유형
Docs-first 방법론
지역화를 위한 작성
마크다운
- 마크다운 내 HTML
- 마크다운에서 헤딩 레벨
- 마크다운 내 역따옴표
언어
- 능동태
- 고객 관점
- 신뢰 구축
- 대문자화
- 가짜 사용자 정보
- 가짜 URL
- 가짜 토큰
- 줄임말
- 소유 형태
- 전치사
- 두문자어
- 숫자
텍스트
- 줄 길이
- 코멘트
- 강조
- 문장부호
- 플레이스홀더 텍스트
- 키보드 명령
- UI에 있는 버튼
- UI에 입력된 텍스트
- 인라인 코드
- 코드 블록
  - 코드 블록 내의 cURL 명령어
목록
- 순서가 있는 목록 또는 순서가 없는 목록 중 선택하기
- 목록 마크업
- 목록 항목 내에 중첩하기
테이블
- 생성 지침
- 테이블 형식 지원을 위한 편집기 확장
- 기존 테이블 업데이트
- 테이블 헤더
- 기능 테이블
- 각주
  - 각주 형식
    - 다섯 개 이상의 각주
인용문
링크
- 앵커 링크
  - 링크 및 제목 변경
- 링크 텍스트
- 외부 문서에 대한 링크
- 비밀 또는 제한된 접근 권한을 가진 링크
- 코드의 특정 라인에 링크 걸기
내비게이션
- 메뉴 이름
- UI 요소 이름
- 내비게이션 작업 단계 작성 방법
- 선택 사항
- 권장 사항
- 여러 필드 한꺼번에 문서화하기
이미지
- 이미지 캡처
- 부각시키기
- 이미지 저장하기
- 이미지 링크를 콘텐츠에 추가하기
- 이미지 압축하기
- 동적 이미지
- 자동 스크린샷 생성기
  - 도구 확장
    - 단일 요소 스크린샷
Emoji
GitLab SVG 아이콘
동영상
- 비디오 링크
- 비디오 임베드
클릭 스루 데모에 대한 링크
경고 상자
- Flag
- Note
- Warning
- Info
- Disclaimer
- Details
Blockquotes
탭
표절
제품 및 기능
- 이름에 줄 바꿈 피하기
- 제품 티어 배지
- 도움 및 피드백 섹션
- GitLab 재시작
- 다양한 설치 방법 문서화 방법
- 자체 관리 구성 절차 설명에 탭 사용
X.Y.1 (페이지 상단에 최신 버전 추가)
- 리눅스 패키지 설치
- 직접 컴파일한 설치
- Geo 설치
X.Y.0

문서 스타일 가이드

이 문서는 GitLab 문서의 기준을 정의하며 문법, 형식, 등에 대한 표준을 제시합니다. 특정 단어에 대한 가이드 라인은 단어 목록을 참조하십시오.

스타일 관련 질문이 있을 경우, 이슈 또는 병합 요청에서 @tw-style을 언급하십시오. 만약 GitLab Slack 워크스페이스에 액세스할 수 있다면 #docs-processes 채널을 이용하십시오.

GitLab의 음성

GitLab 브랜드 가이드라인은 조직 전체에서 사용되는 음성을 정의합니다.

이를 바탕으로 GitLab 문서의 음성은 간결하고, 직접적이며 정확하도록 노력합니다. 목표는 쉽게 검색하고 스캔할 수 있는 정보를 제공하는 것입니다.

문서에서의 음성은 대화 형식이지만 간결하며, 친근하지만 간결해야합니다.

문서는 단일 정보 원천입니다 (SSoT)

GitLab 문서는 구현, 사용 및 문제 해결과 관련된 모든 제품 정보에 대한 SSoT입니다. 문서는 지속적으로 발전합니다. 새로운 제품과 기능, 그리고 명료성, 정확성, 완결성을 위한 개선 사항이 반영됩니다.

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

주제 유형

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

주제 유형은 사용자가 정보를 더 빨리 이해할 수 있도록 돕습니다. 또한 다음과 같은 문제를 해결하는 데 도움이 됩니다.

콘텐츠가 찾기 어렵습니다. GitLab 문서는 포괄적이며 많은 양의 유용한 정보를 포함합니다. 주제 유형은 콘텐츠를 빠르게 스캔하고 해석할 수 있는 되풀이되는 패턴을 만듭니다.
콘텐츠가 종종 기여자의 관점에서 작성됩니다. GitLab 문서는 다양한 기여자에 의해 작성됩니다. 주제 유형(특히 작업)은 기능이 어떻게 구현되었는지에 대한 문서화보다는 다른 사람을 돕기 위한 형식으로 정보를 제공할 수 있도록 돕습니다.

Docs-first 방법론

제품 문서는 완전하고 신뢰할 수 있는 자원이어야 합니다.

질문의 답이 문서에 이미 존재하는 경우, 정보를 다시 정리하는 대신 문서의 링크를 공유하십시오.
GitLab 문서에 없는 정보를 발견하면 해당 정보를 문서에 추가하기 위해 병합 요청(MR)를 작성하십시오. 그런 다음 MR을 공유하여 정보를 전파하십시오.

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

지역화를 위한 작성

GitLab 문서는 지역화되지 않지만, 우리는 글로벌 관객을 위해 작성하는 데 도움이 되는 지침을 따릅니다.

GitLab 음성 에 따르면 번역을 고려하여 명확하고 직접적으로 작성해야합니다. 우리의 스타일 가이드 단어 목록, 및 Vale 규칙은 문서의 일관성을 보장합니다.

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

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

피하세요:

there is and there are와 같이 주어를 숨기는 구에서 출발한 구 변경.
it와 같이 모호한 대명사.
-ing로 끝나는 단어.
since와 because와 같이 서로 혼동될 수 있는 단어.
e.g.와 i.e.와 같이 라틴 축약어.
kill two birds with one stone과 같은 문화적인 레퍼런스.

사용하세요:

표준적인 링크 텍스트.
복잡한 문장과 단락 대신 목록 및 테이블.
AI 및 CI/CD와 같은 일반적인 약어 및 이전에 철자로 표기한 약어.
기능명과 그와 상호작용하는 방식에 일관성을 유지하십시오.
명사 구를 분리하십시오. 예를 들어, project integration custom settings 대신에 custom settings for project integrations를 사용하십시오.
날짜와 시간을 국제 관객을 대상으로 일관되게 형식화하십시오.
스크린샷을 포함한 이미지는 절약하여 사용하십시오.
UI 텍스트에서 번역된 문자열이 30%까지 확장 또는 축소될 수 있도록 합니다. 다른 언어에서 문자열이 얼마나 확장 또는 축소되는지 알아보려면 문자열을 Google 번역에 붙여 넣고 결과를 확인하십시오. 해당 언어를 구사하는 동료에게 번역이 명확한 지 확인할 수 있습니다.

마크다운

모든 GitLab 문서는 마크다운으로 작성됩니다.

문서 웹사이트는 GitLab Kramdown을 사용하여 마크다운을 HTML로 렌더링하는 “flavored” Kramdown 엔진을 사용합니다. Kramdown 사용은 우리의 린터에 의해 제한되므로, 일반 마크다운을 사용하고 연결된 스타일 가이드의 규칙을 따르십시오. Kramdown 특정 마크업(예: {:.class})을 사용할 수 없습니다.

완전한 Kramdown 참조사항은 GitLab 마크다운 가이드를 참조하십시오.

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

마크다운 내 HTML

하드코딩된 HTML은 유효하지만 사용을 자제해야 합니다. HTML은 다음과 같은 경우에 허용됩니다:

마크다운에 해당하는 마크업이 없을 때.
고급 테이블이 필요한 경우.
특별한 스타일이 필요한 경우.
기술적인 작성자에 의해 검토 및 승인되었을 때.

마크다운에서 헤딩 레벨

각 문서 페이지는 1단계 제목(#)로 시작합니다. 이는 페이지를 HTML로 렌더링할 때 h1 요소가 됩니다. 페이지 당 하나의 1단계 제목만 허용됩니다.

각 하위 섹션에 대해 헤딩 레벨을 증가시킵니다. 다시 말해서, 주제 제목 앞의 # 문자의 수를 증가시킵니다.
H5 (#####)를 초과하는 헤딩 레벨을 피하십시오. 다섯 개 이상의 헤딩 레벨이 필요한 경우 주제를 새 페이지로 이동시키십시오. H5를 초과하는 헤딩 레벨은 오른쪽 사이드바 내비게이션에 표시되지 않습니다.
레벨을 건너뛰지 마십시오. 예: ## > ####.
주제 제목 앞뒤로 한 줄을 비워두십시오.
주제 제목에 코드를 사용하는 경우 코드가 역따옴표 안에 있는지 확인하십시오.

마크다운 내 역따옴표

다음과 같은 경우에 역따옴표를 사용하십시오:

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

언어

GitLab 문서는 명확하고 이해하기 쉬워야 합니다.

불필요한 단어를 피하십시오.
목적에 명확하고 간결하게 유지하십시오.
미국 영어로 쓰고 미국식 문법을 사용하십시오. ( British.yml에서 테스트됨).

능동태

대부분의 경우, 수동태 대신 능동태를 사용하면 텍스트를 이해하고 번역하기 쉬워집니다.

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

개발자는 애플리케이션을 위해 코드를 작성합니다.

대신 다음과 같이 사용하십시오:

애플리케이션 코드는 개발자에 의해 작성됩니다.

가끔씩 ‘GitLab’을 주체로 사용하는 것이 부자연스러울 수 있습니다. 예를 들면, ‘GitLab이 보고서를 내보냅니다’. 이 경우 수동태를 사용할 수 있습니다. 예를 들면, ‘보고서가 내보내집니다’.

고객 관점

고객에게 제공하는 기능과 이점에 중점을 두십시오, GitLab이 만든 것에 중점을 두는 대신.

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

병합 요청을 사용하여 소스 및 대상 브랜치의 코드를 비교합니다.

대신 다음과 같이 사용하지 마십시오:

GitLab을 사용하여 코드를 비교할 수 있습니다.
GitLab이 코드를 비교할 수 있도록 했습니다.
병합 요청을 사용하여 코드를 비교할 수 있습니다.

고객 관점에서 작성하고 있지 않다는 것을 나타내는 단어는 허용하고 가능하게 하다입니다. 대신 you를 사용하고 사용자에게 직접적으로 말하는 것을 시도하십시오.

신뢰 구축

제품 문서는 판매나 마케팅 텍스트를 덧붙이지 않고 명확하고 간결한 정보를 제공하는 데 중점을 두어야 합니다.

easily나 simply와 같은 단어를 사용하지 마십시오.
“이 기능은 시간과 비용을 절약할 것입니다.”와 같은 마케팅 구절을 사용하지 마십시오.

대신 사실과 달성 가능한 목표에 집중하십시오. 구체적일 때 더 좋습니다. 예를 들어:

이 기능을 사용하면 빌드 시간을 줄일 수 있습니다.
이 기능을 사용하면 프로젝트를 생성할 때 시간을 절약할 수 있습니다. 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.

엔티티의 권위 있는 출처에서 명명 방식을 따르되, 해당 출처가 비표준 대소문자 형식을 사용할 수도 있습니다. 예를 들어: GitLab 및 npm.

가짜 사용자 정보

REST 호출 또는 사용자 프로필과 같은 항목에 사용자 정보를 포함해야 할 수 있습니다. GitLab 문서에서는 실제 사용자 정보나 이메일 주소를 사용하지 마십시오.

이메일 주소: example.com으로 끝나는 이메일 주소를 사용합니다.
이름: example_username과 같은 문자열을 사용하십시오. 또는 일반적인 성을 가진 다양하거나 성별 중립적인 이름을 사용하십시오. 예: Sidney Jones, Zhang Wei, 또는 Alex Garcia.

가짜 URL

문서에 샘플 URL을 포함해야 할 때는 다음을 사용하십시오:

일반적인 도메인 이름을 사용하는 경우 example.com을 사용합니다.
관리형 GitLab 인스턴스에만 언급되는 경우 gitlab.example.com을 사용하십시오. GitLab SaaS 인스턴스의 경우 gitlab.com을 사용하십시오.

가짜 토큰

cURL을 사용하여 API 호출을 보여주거나 CI에서 사용되는 변수를 나타내기 위해 때로는 토큰이 필요할 수 있습니다. 낮은 확률로 토큰이 악용될 가능성이 있더라도 문서에서 실제 토큰을 사용하는 것은 강력히 권장하지 않습니다.

다음과 같은 가짜 토큰을 예시로 사용할 수 있습니다:

토큰 유형	토큰 값
개인 액세스 토큰	`<your_access_token>`
애플리케이션 ID	`2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6`
애플리케이션 시크릿	`04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df`
CI/CD 변수	`Li8j-mLUVA3eZYjPfd_H`
프로젝트 러너 토큰	`yrnZW46BrtBFqM7xDzE7dddd`
공유 러너 토큰	`6Vk7ZsosqQyfreAxXTZr`
트리거 토큰	`be20d8dcc028677c931e04f3871a9b`
웹훅 보안 토큰	`6XhDroRcYPM5by_h-HLY`
헬스 체크 토큰	`Tu7BgjR9qeZTEyRzGG2P`

줄임말

줄임말 사용을 장려하며, 튜토리얼, 지침 문서 및 사용자 인터페이스에서 편안하고 비공식적인 어조를 만들 수 있습니다.

그러나 일부 줄임말은 피해야 합니다:

줄임말을 사용하지 마십시오	예시	대신 사용
고유 명사와 동사 함께 사용	Terraform’s a helpful tool.	Terraform is a helpful tool.
부정을 강조하기 위해 사용	Don’t install X with Y.	Do not install X with Y.
참조 문서에서 사용	Don’t set a limit.	Do not set a limit.
에러 메시지에서 사용	Requests to localhost aren’t allowed.	Requests to localhost are not allowed.

소유 형태

명사에 소유불명사('s) 사용을 피하도록 노력하십시오.

예를 들어 Docker's CLI 대신 the Docker CLI를 사용하십시오.

자세한 내용은 Google 문서 작성 스타일 가이드를 참조하십시오.

전치사

필요한 경우 문장 뒤에 전치사를 사용하십시오. 문장 끝에 놓여 있는 또는 떨어져 있는 전치사도 괜찮습니다. 예를 들어:

당신이 소속된 그룹을 떠날 수 있습니다.
액세스를 부여하고 싶은 사용자와 자격 증명을 공유하십시오.

이러한 구조는 대체로 대체적인 것보다 느슨한 것으로 간주됩니다:

당신이 소속된 그룹을 떠날 수 있습니다.
액세스를 부여하고 싶은 사용자의 경우, 자격 증명을 공유하십시오.

두문자어

두문자어를 사용하는 경우 페이지에서 최초로 사용할 때 전체 표기된 상태로 써주십시오. 페이지에서 한 번 이상 표기를 다시 할 필요는 없습니다.

제목: 특히 두문자어가 널리 사용되고 있지 않은 경우 토픽 제목에서 두문자어를 피하십시오.
복수형: 두문자어를 복수형으로 표기하지 않도록 노력하십시오. 예를 들어 YAML files 대신 YAMLs를 사용하지 마십시오. 반드시 두문자어를 복수로 표현해야 하는 경우에는 아포스트로피를 사용하지 마십시오. 예를 들어 APIs 대신 API's를 사용하지 마십시오.
소유형: 두문자어를 소유형으로 표현할 때 주의하십시오. 되도록 소유형으로 만들지 않도록 문장을 구성하십시오. 반드시 두문자어를 소유형으로 표현해야 하는 경우에는 문구를 완전히 쓰는 것을 고려하십시오.

숫자

텍스트 내 숫자는 0부터 9까지는 영어로 쓰고, 10 이상은 숫자로 표기하세요. 더 많은 정보는 Microsoft Style Guide를 참조하세요.

텍스트

마크다운으로 작성하세요.
새 단락을 나타내려면 빈 줄을 삽입하세요.
서로 다른 마크업 간에는 빈 줄을 삽입하세요(예를 들어, 각 단락, 제목, 목록 등 뒤에).
```
## 제목

단락.

- 목록 항목 1
- 목록 항목 2
```

줄 길이

원문을 쉽게 읽기 위해, 그리고 변경 사항을 더 쉽게 비교하기 위해 가능한 경우에는 다음의 모범 사례를 따르세요.

긴 줄은 대략 100자쯤에서 나누세요.
각 새로운 문장을 새 줄에서 시작하세요.

코멘트

마크다운 내에서 코멘트를 포함하려면 발행될 때 렌더링되지 않는 표준 HTML 코멘트를 사용하세요. 예:

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

강조

강조를 표시할 때 이탤릭 대신 굵게 사용하세요. GitLab은 산세리프 글꼴을 사용하며, 이탤릭 텍스트는 세리프 글꼴에서 표시되는 것만큼 눈에 띄지 않습니다. 자세한 내용은 Butterick’s Practical Typography guide on bold or italic를 참조하세요.

용어를 처음 소개할 때에는 이탤릭을 사용할 수 있습니다. 그 이외의 경우에는 굵은체를 사용하세요.

단어나 텍스트를 굵게 표시하려면 별표(**)를 사용하세요(**굵은체**).
이탤릭체로 표시하려면 밑줄(_)을 사용하세요(_이탤릭_).
인용구로 표시하려면 큰 부호(>)를 사용하세요.

문장부호

다음 가이드라인을 따라 문장부호를 사용하세요.

마침표로 완전한 문장을 끝내세요. 표 내의 완전한 문장에도 마침표를 사용하세요.
리스트의 세 번째 이상의 항목에서 마지막 and나 or 앞에 항목을 구분하기 위해 일련(옥스포드) 쉼표를 사용하세요. (‘OxfordComma.yml’에서 테스트됨).

콘텐츠를 띄울 때:

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

다음 문장 부호를 사용하지 마세요:

; (세미콜론): 대신 두 문장을 사용하세요.
– (엔 대시) 또는 — (엠 대시): 대시 또는 쉼표를 사용하세요.
“ ” ‘ ’: 곡선 인용 부호 또는 직선 인용 부호 대신 직선 인용 부호를 사용하세요. (‘NonStandardQuotes.yml’에서 테스트됨).

플레이스홀더 텍스트

코드 블록에서는 독자가 특정 값을 자신의 값으로 교체해야 하는 경우 <와 >를 사용하여 표시하세요.

예를 들어:

cp <원본디렉토리> <대상디렉토리>

코드 블록이 아닌 경우에는 <와 >를 사용하고 플레이스홀더를 하나의 백틱으로 감싸세요. 예를 들어:

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

키보드 명령

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

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

문서가 생성될 때 출력은:

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

UI에 있는 버튼

가시적인 레이블이 있는 요소에 대해 굵은체로 일치하는 케이스의 레이블을 사용하세요.

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

UI에 입력된 텍스트

UI에서 사용자로 하여금 어떤 것을 입력하도록 하려면 백틱을 사용하세요. 예를 들어:

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

따옴표보다 백틱이 더 정확합니다. 예를 들어, 다음 문자열에서:

커밋 메시지 텍스트 상자에 “이것은 제 병합 요청입니다.”를 입력하세요.

사용자가 문장부호를 포함해야 하는지 여부가 명확하지 않습니다.

인라인 코드

인라인 코드 스타일은 일반 텍스트와 함께 인라인으로 적용됩니다. 인라인 코드 스타일을 사용하는 경우:

파일 이름 또는 구성 파일 조각에 사용됩니다. 예: .gitlab-ci.yml, CODEOWNERS, 그리고 only: [main].
HTTP 메소드 (HTTP POST) 및 HTTP 상태 코드에 사용되며, 전체 (404 File Not Found) 및 약어화된 (404) 상태 코드를 포함합니다. 예: Runner를 삭제하려면 DELETE 요청을 보냅니다. 하나를 생성하려면 POST 요청을 보냅니다.

인라인 코드 스타일을 적용하려면 텍스트를 단일 반딧기 (`)로 감쌉니다. 예: 이것은 인라인 코드 스타일입니다.

코드 블록

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

코드 블록 스타일을 적용하려면 텍스트를 세 번의 반딧기 (3 개의 `)로 감싸고 구문 강조 힌트를 추가합니다. 예를 들면:

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

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

스타일을 적용하는 코드 블록에 세 번의 반딧기가 있는 경우 네 번의 백틱 (4 개의 `)을 사용합니다. 예: 코드 블록 스타일을 설명할 때.
코드 블록 위와 아래에 공백 줄을 추가합니다.
코드 블록에는 구문 강조 힌트가 필요합니다. 사용 가능한 구문 강조기에 대한 정보는 지원되는 언어 및 렉서 목록을 참조하십시오. 더 나은 힌트가 없는 경우 plaintext를 사용합니다.

코드 블록 내의 cURL 명령어

cURL 명령어의 스타일에 관한 정보는 cURL 명령어를 참조하십시오.

정보를 쉽게 스캔할 수 있는 형식으로 제시하기 위해 목록을 사용하세요.

목록의 모든 항목은 병렬해야 합니다. 예를 들어, 일부 항목을 명사로 시작하고 다른 항목을 동사로 시작하지 마십시오.
문구가 완전한 문장이 아닌 경우 마침표를 사용하지 마십시오.
모든 문장 뒤에는 마침표를 사용하십시오. 세미콜론이나 쉼표를 사용하지 마십시오.
모든 항목에 동일한 구두점을 사용하십시오.
각 항목은 대문자로 시작하십시오.

소개구와 설명 텍스트를 콜론 (:)으로 구분하십시오. 예:

다음을 할 수 있습니다:

- 이 작업을 수행하십시오.
- 다른 작업을 수행하십시오.

순서가 있는 목록 또는 순서가 없는 목록 중 선택하기

단계별 순서가 지정된 목록을 사용하여 단계 시퀀스를 제공하십시오. 예를 들어:

무언가를 수행하려면 다음 단계를 따르십시오.

먼저 첫 번째 단계를 수행하십시오.
그런 다음 다음 단계를 수행하십시오.
마지막으로 마지막 단계를 수행하십시오.

순서에 상관없이 완료해야 하는 단계가 있는 경우 순서가 지정되지 않은 목록을 사용하십시오. 예:

다음 사항을 가져왔습니다:

- 사물 1
- 사물 2
- 사물 3

목록 마크업

순서가 없는 목록에는 별표(*) 대신 대시(-)를 사용하십시오.
정렬된 목록의 모든 항목을 1.로 시작하십시오. 렌더링되면 목록 항목이 순차적으로 표시됩니다.
목록 앞 뒤에 빈 줄을 남기십시오.
들여쓰기된 하위 항목을 나타내기 위해 줄을 시작할 때 공백을 사용하십시오 (목록 항목 내에 중첩 참조).

목록 항목 내에 중첩하기

목록 항목 아래에 항목을 중첩하여 동일한 들여쓰기로 렌더링되게 할 수 있습니다. 이는 다음과 같은 항목을 사용하여 수행할 수 있습니다:

코드 블록
인용구
알림 상자
이미지
탭

중첩된 항목은 항상 목록 항목의 첫 번째 문자와 맞아야 합니다. 순서가 지정되지 않은 목록(- 사용)의 경우 각 수준의 들여쓰기에 두 개의 공백을 사용하십시오:

- 순서가 지정되지 않은 목록 항목 1

  `U`와 일치시키기 위해 2 개의 공백을 사용하여 네스트된 줄.

- 순서가 지정되지 않은 목록 항목 2

  > 목록 항목 2 내부에 중첩되는 인용 블록.
  > 

  - 순서가 지정되지 않은 목록 항목 3

  ```plaintext
  목록 항목 3 내부에 중첩되는 코드 블록
  ```

- 순서가 지정되지 않은 목록 항목 4

  목록 항목 4 내부에 중첩되는 이미지

순서가 지정된 목록의 경우 각 수준의 들여쓰기에 세 개의 공백을 사용하십시오:

1. 순서가 지정된 목록 항목 1

   `O`와 일치시키기 위해 3 개의 공백을 사용하여 네스트된 줄.

목록 내에서 목록을 중첩시킬 수 있습니다.

1. 순서가 지정된 목록 항목 하나.
1. 순서가 지정된 목록 항목 둘.
   - 중첩된 순서가 지정되지 않은 목록 항목 하나.
   - 중첩된 순서가 지정되지 않은 목록 항목 둘.
1. 순서가 지정된 목록 항목 세.

- 순서가 지정되지 않은 목록 항목 하나.
- 순서가 지정되지 않은 목록 항목 둘.
  1. 중첩된 순서가 지정된 목록 항목 하나.
  1. 중첩된 순서가 지정된 목록 항목 둘.
- 순서가 지정되지 않은 목록 항목 세.

테이블

테이블은 복잡한 정보를 명확하게 설명하는 데 사용되어야 합니다. 대부분의 경우, 항목의 목록을 간단한 설명으로 설명하는 데는 정렬되지 않은 목록이 충분하지만 매트릭스로 가장 잘 설명되는 데이터가 있을 경우 테이블이 최선의 선택입니다.

생성 지침

테이블을 접근 가능하고 쉽게 검토할 수 있도록 비어있는 셀이 없어야 합니다. 셀에 의미 있는 값이 없는 경우 “해당 없음”을 위해 N/A 또는 None을 입력하는 것을 고려해 보세요.

테이블을 유지 관리하기 쉽도록 하려면 다음을 할 수 있습니다:

열 너비를 일관되게 유지하려면 추가 공백을 추가하세요. 예를 들어:

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

매우 넓은 테이블의 경우 최우측 열에 추가 공백을 생략하세요. 예를 들어:

| 설정     | 기본값   | 설명         |
|---------|---------|-------------|
| 설정 1   | `1000`  | 간단한 설명. |
| 설정 2   | `2000`  | 이 열의 모든 셀을 정렬하면 테이블이 너무 넓어지고 너무 많은 공백이 생기므로 테이블이 너무 넓어집니다. |
| 설정 3   | `0`     | 다른 간단한 설명. |

테이블 형식 지원을 위한 편집기 확장

모든 Markdown 파일에서 일관된 테이블 형식을 보장하려면 VS Code Markdown Table Formatter를 사용하여 테이블을 형식화하는 것을 고려해 보세요. 이 확장 프로그램을 구성하여 위의 지침을 따르도록 설정하세요.

설정하는 방법:

UI에서:
1. VS Code 메뉴에서 Code > Settings > Settings로 이동합니다.
2. Limit Last Column Length를 검색합니다.
3. Limit Last Column Length 드롭다운 목록에서 Follow header row length를 선택합니다.

VS Code settings.json에서 다음과 같이 새로운 줄을 추가하세요:

{
  "markdown-table-formatter.limitLastColumnLength": "Follow header row length"
}

이 확장 프로그램을 사용하여 테이블을 형식화하려면 전체 테이블을 선택한 후 해당 부분을 마우스 오른쪽 버튼으로 클릭하고 Format Selection With를 선택하세요. 그런 다음 VS Code 명령 팔레트에서 Markdown Table Formatter를 선택하세요.

또는 Sublime Text를 사용하는 경우 Markdown Table Formatter 플러그인을 사용해 볼 수 있지만 Follow header row length 설정은 포함되어 있지 않습니다.

기존 테이블 업데이트

기존 테이블에 행을 추가하거나 편집하는 경우 새 행의 셀은 더 넓을 수 있습니다. 너비를 고려하여 열을 재정렬하면 전체 테이블이 수정된 것으로 나타나기 때문에 차이를 읽기가 어려워집니다.

Markdown 테이블은 시간이 지남에 따라 자연스럽게 정렬이 틀어지지만 docs.gitlab.com에서는 여전히 올바르게 렌더링됩니다. 기술 문서 팀은 페이지가 리팩토링될 때 다음에 셀을 다시 정렬할 수 있습니다.

테이블 헤더

테이블 헤더에는 문장 케이스를 사용하세요. 예: 키워드 값 또는 프로젝트 이름.

기능 테이블

기능 목록의 테이블(예: 권한 페이지에서 각 역할에 대한 사용 가능한 기능)을 만들 때 다음 구문을 사용하세요:

옵션	Markdown	표시 결과
No	`{dotted-circle} No`	No
Yes	`{check-circle} Yes`	Yes

API 문서에서는 **{dotted-circle}**와 **{check-circle}** 대신 API 주제 템플릿을 따르세요.

각주

테이블 아래에 내용을 테이블 자체에 포함시킬 수 없는 경우에만 각주를 사용하세요. 예를 들어:

여러 테이블 셀에서 동일한 정보를 제공해야 하는 경우.
테이블 레이아웃을 방해하는 콘텐츠를 포함해야 하는 경우.

각주 형식

테이블에서 각주를 추가할 때 각주마다 HTML 슈퍼스크립트 태그 <sup>를 사용하세요. 태그를 마침표 다음에 끝에 넣으세요.

예를 들어:

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

각주를 추가할 때 테이블 내에서 기존 태그를 재정렬하지 마세요.

테이블 아래에 각주를 추가할 때 **각주:** 다음에 순서가 매겨진 목록을 사용하세요.

예를 들어:

**각주:**

1. 이것은 첫 번째 각주입니다.
1. 이것은 두 번째 각주입니다.

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

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

각주:

이것은 첫 번째 각주입니다.
이것은 두 번째 각주입니다.

다섯 개 이상의 각주

표 자체에 포함시키지 못할 다섯 개 이상의 각주가 있다면, 연속적인 번호를 사용할 수 있습니다. 연속적인 번호를 사용하는 경우 Markdown 규칙 029를 비활성화해야 합니다:

**각주:**

<!-- 순서가 지정된 목록 규칙 비활성화 https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029 -->
<!-- markdownlint-disable MD029 -->

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

<!-- markdownlint-enable MD029 -->

인용문

Markdown 콘텐츠에만 해당되는 유효한 인용문:

표준 인용문: 이중 인용부호("). 예: “이것은 이중 인용부호 안에 포함됩니다”.
인용문 안의 인용문: 이중 인용부호(")가 한 인용부호(')를 감쌉니다. 예: “이 문장은 ‘인용 내용’을 가진 인용문 내부에 있습니다”.

다른 구두점 규칙에 대해서는 Pajamas Design System Punctuation section을 참조하세요. 이는 문서별 구두점 규칙에 의해 재정의됩니다.

링크

링크는 문서의 단일한 진실의 출처 원칙을 준수하는 데 도움이 됩니다.

그러나 한 페이지에 너무 많은 링크를 넣지 않는 것이 좋습니다. 너무 많은 링크는 가독성을 해칠 수 있습니다.

같은 페이지에서 링크를 중복해서 넣지 마세요. 예를 들어, 페이지 A에서 페이지 B로 여러 번 링크를 걸지 마세요.
하나의 문단에 여러 링크를 피하세요.
한 페이지에서 다른 페이지로의 링크를 15개 이상 사용하지 마세요.
관련 주제를 사용하여 작업의 흐름을 방해하는 링크를 줄이는 것을 고려하세요.
같은 저장소에서 다른 페이지로 링크하는 경우, 상대 파일 경로를 사용하세요. 예: ../user/gitlab_com/index.md.

인라인 링크 Markdown 마크업[텍스트](https://example.com)를 사용하고 참조 스타일 링크([Text][identifier]) 대신에 사용하세요.

린터가 이를 찾을 수 있도록 링크 전체를 한 줄에 넣으세요.

다른 저장소에 있는 페이지로 링크를 걸기 위해서는 절대 URL을 사용하세요. 예를 들어, GitLab 저장소의 페이지에서 Charts 저장소로 링크를 걸기 위해서는 https://docs.gitlab.com/charts/와 같은 URL을 사용하세요.

앵커 링크

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

페이지의 첫 번째 주제 제목(h1)에는 앵커 링크가 있지만 사용하지 마세요. 대신에 페이지로 링크를 걸어주세요.

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

주제 제목 텍스트를 변경하면 앵커 링크도 변경됩니다. 깨진 링크를 방지하려면:

주제 제목에서 단계 번호를 사용하지 마세요.
가능한 경우, 미래에 바뀔 수 있는 단어를 사용하지 마세요.

링크 및 제목 변경

주제 제목을 변경하면 앵커 링크도 변경됩니다. 관련 링크를 업데이트하려면 다음 디렉터리를 검색하세요:

doc/*
app/views/*
ee/app/views/*

이러한 링크를 수정하지 않으면, 당신의 병합 요청에서 ui-docs-lint 작업이 실패합니다.

링크 텍스트

링크 텍스트에 대한 지침을 따르세요.

표준 텍스트

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

자세한 내용은 [링크 텍스트](링크)를 참조하세요.
[작업을 수행하려면] [링크 텍스트](링크)를 참조하세요

예를 들어:

자세한 내용은 [병합 요청](LINK)을 참조하세요.
리뷰 앱을 만들려면 [리뷰 앱](LINK)을 참조하세요.

이 텍스트를 통해 “이 기능에 대한 더 많은 정보”와 같은 구문을 사용하여 이 텍스트를 확장할 수 있습니다.

다음 구조를 사용하지 마세요:

...에 대해 더 알아보기
...을 읽으려면
자세한 내용은 [병합 요청](LINK) 페이지를 참조하세요.
자세한 내용은 [병합 요청](LINK) 문서를 참조하세요.

‘여기’보다 구체적인 텍스트

링크에 대해 ‘여기’나 ‘이 페이지’와 같은 단어 대신에 구체적인 텍스트를 사용하세요.

예:

자세한 내용은 [이 페이지](LINK)를 참조하세요.
자세한 내용은 [여기](LINK)에서 확인하세요.

대신에 사용하세요:

자세한 내용은 [병합 요청](LINK)을 참조하세요.

이슈에 대한 링크

이슈에 링크를 걸 때는 링크에 이슈 번호를 포함하세요. 예시:

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

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

외부 문서에 대한 링크

가능한 경우, 외부 문서에 대한 링크를 피하십시오. 이러한 링크는 쉽게 오래된 상태가 될 수 있으며 유지 관리하기 어렵습니다.

가끔씩 링크가 필요할 수 있습니다. 이 링크는 문제 해결 단계를 명확히하거나 콘텐츠의 중복을 방지하는 데 도움이 될 수 있습니다. 때로는 더 정확하고 더 활발하게 관리될 수 있습니다.

추가한 각 외부 링크마다 고객이 누리게 되는 혜택과 유지 관리 어려움을 따져보세요.

비밀 또는 제한된 접근 권한을 가진 링크

다음과 같은 것들에 직접적으로 링크를 걸지 마세요:

비밀 이슈
내부 핸드북 페이지
특별한 권한을 필요로 하는 프로젝트 기능

이러한 링크는 다음과 같은 이유로 실패합니다:

충분한 권한이 없는 사용자는 접근할 수 없습니다.
자동 링크 체커의 실패

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

링크가 비밀 이슈 또는 내부 핸드북 페이지를 가리킨다면, 해당 이슈나 페이지가 GitLab 팀 멤버에게만 보인다고 언급하십시오.
링크가 특정 역할이나 권한을 필요로 한다면, 그 정보를 언급하십시오.
링크가 링크 체커의 실패를 일으키지 않도록 백틱에 넣어두십시오.

예시:

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`

코드의 특정 라인에 링크 걸기

파일의 특정 라인에 링크를 걸 때, 브랜치 대신 커밋에 링크를 걸어야 합니다. 코드 라인은 시간이 지남에 따라 변경되기 때문에 커밋 링크를 사용하여 특정 라인으로 이동할 수 있도록 해야 합니다. 프로젝트의 파일을 보는 동안 표시되는 퍼머링크 버튼은 해당 파일의 가장 최근 커밋에 대한 링크를 제공합니다.

올바른 방법: [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).

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

항상 위치, 그 다음 동작을 사용하세요.
- 가시성 드롭다운 목록(위치)에서 공개를 선택하세요(동작).
간결하고 구체적으로 작성하세요. 예시:
- 옳은 방법: 저장을 선택하세요.
- 잘못된 방법: 변경 사항이 적용되려면 저장을 선택하세요.
만약 단계가 이유를 포함해야 한다면, 해당 단계로 시작해주세요. 이는 사용자가 더 빨리 스캔할 수 있도록 도와줍니다.
- 옳은 방법: 변경 사항을 보려면, 병합 요청에서 링크를 선택하세요.
- 잘못된 방법: 변경 사항을 보려면, 병합 요청에서 링크를 선택하세요.

메뉴 이름

다음과 같은 용어들을 사용하여 주요 GitLab 사용자 인터페이스 요소를 참조할 때 이용해주세요:

왼쪽 사이드바: 이것은 사용자 인터페이스의 왼쪽에 있는 내비게이션 사이드바입니다.
- context switcher나 switch contexts와 같은 구문을 사용하지 마세요. 대신, 특정 위치로 사용자를 세부적인 스텝의 일련으로 안내하도록 노력해주세요.
- 탐색 메뉴나 당신의 작업 사이드바와 같은 문구를 사용하지 마세요. 대신, 왼쪽 사이드바를 사용하세요.
오른쪽 사이드바: 이것은 열려있는 이슈, 병합 요청 또는 이픽에 특화된 사용자 인터페이스 오른쪽에 있는 내비게이션 사이드바입니다.

UI 요소 이름

버튼과 체크박스와 같은 UI 요소의 이름은 굵은체로 표시되어야 합니다. 개별 UI 요소에 대한 가이드는 단어 목록에 있습니다.

내비게이션 작업 단계 작성 방법

일관성을 유지하기 위해, 작업 주제의 내비게이션 단계를 작성할 때 이 예시를 사용해주세요. 대안적인 단계들이 존재할 수 있기는 하지만, 기본적으로 고정으로 설정된 항목 또는 항목을 사용하지 말고 아래의 단계들을 사용해주세요.

프로젝트 설정을 열도록 하기 위해서:

왼쪽 사이드바에서 **검색 또는 이동**을 선택하고 프로젝트를 찾아보세요.
**설정 > CI/CD**를 선택하세요.
**일반 파이프라인**을 펼쳐보세요.

그룹 설정을 열도록 하기 위해서:

왼쪽 사이드바에서 **검색 또는 이동**을 선택하고 그룹을 찾아보세요.
**설정 > CI/CD**를 선택하세요.
**일반 파이프라인**을 펼쳐보세요.

프로젝트 또는 그룹 설정을 열도록 하기 위해서:

왼쪽 사이드바에서 **검색 또는 이동**을 선택하고 프로젝트나 그룹을 찾아보세요.
**설정 > CI/CD**를 선택하세요.
**일반 파이프라인**을 펼쳐보세요.

프로젝트를 생성하도록 하기 위해서:

1. 왼쪽 사이드바의 맨 위에서 **새로 만들기** (**{plus}**) 및 **새 프로젝트/저장소**를 선택하세요.

그룹을 생성하도록 하기 위해서:

1. 왼쪽 사이드바의 맨 위에서 **새로 만들기** (**{plus}**) 및 **새 그룹**를 선택하세요.

Admin Area를 열도록 하기 위해서:

1. 왼쪽 사이드바의 맨 아래에서 **Admin Area**를 선택하세요.
1. **설정 > CI/CD**를 선택하세요.

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

당신의 작업 메뉴 항목을 열도록 하기 위해서:

1. 왼쪽 사이드바에서 **검색 또는 이동**을 선택하세요.
1. **당신의 작업**을 선택하세요.

아바타를 선택하도록 하기 위해서:

1. 왼쪽 사이드바에서 아바타를 선택하세요.

일부 드롭다운 목록에서 선택을 저장하도록 하기 위해서:

당신의 이슈로 이동하세요.
**우측 사이드바**에서 **이터레이션** 섹션에서 **편집**을 선택하세요.
드롭다운 목록에서 이 이슈와 연결할 이터레이션을 선택하세요.
드롭다운 목록 외부의 어느 영역이든 선택하세요.

모든 프로젝트를 보도록 하기 위해서:

1. 왼쪽 사이드바에서 **검색 또는 이동**을 선택하세요.
1. **내 프로젝트 모두 보기**를 선택하세요.

모든 그룹을 보도록 하기 위해서:

1. 왼쪽 사이드바에서 **검색 또는 이동**을 선택하세요.
1. **내 그룹 모두 보기**를 선택하세요.

선택 사항

단계가 선택 사항인 경우, 단계 앞에 Optional이라는 단어를 사용한 후 마침표를 찍습니다.

예시:

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

권장 사항

단계가 권장되는 경우, 단계 앞에 Recommended라는 단어를 사용한 후 마침표를 찍습니다.

예시:

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

여러 필드 한꺼번에 문서화하기

UI 텍스트가 섹션의 필드를 충분히 설명하는 경우, 모든 필드에 대한 작업 단계를 포함하지 않습니다. 대신, 여러 필드를 한 번의 작업 단계로 요약합니다.

필드를 완료라는 구문을 사용합니다.

예시:

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

여러 필드를 문서화해야 하는 경우 하나의 필드만 설명하면 됩니다:

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

여러 필드를 설명하는 경우, 순서 없는 목록 항목을 사용합니다:

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

이미지

이미지, 스크린샷을 포함하여 독자가 개념을 더 잘 이해할 수 있습니다. 그러나 이러한 이미지는:

낡아지기 쉽습니다.
번역하기 어렵고 비용이 많이 소요됩니다.
스크린 리더에서 인식할 수 없습니다.

필요한 경우, 이미지를 사용하여 독자가 다음을 이해하도록 도와줍니다:

복잡한 프로세스에서 어디에 있는지.
어떻게 애플리케이션과 상호 작용해야 하는지.

이미지 캡처

스크린샷을 찍을 때:

유효한 정보를 제공하는지 확인합니다. lorem ipsum 텍스트를 사용하지 마십시오. 실제 시나리오에서 해당 기능이 사용될 것으로 가정하고, 현실적인 텍스트를 사용합니다.
관련 있는 UI만 포함됩니다. 불필요한 여백이나 포인트를 설명하지 않는 부분은 제외합니다. GitLab의 사이드바는 변경될 수 있으므로 반드시 필요한 경우를 제외하고 스크린샷에 포함하지 않습니다.
크기를 작게 유지합니다. 전체 화면 폭을 보여줄 필요가 없다면, 사용하지 않습니다. 브라우저 창을 최소화하여 요소를 가깝게 유지하고 빈 공간을 줄입니다. 스크린샷의 크기를 가능한 한 작게 유지합니다.
페이지에서 이미지 렌더링을 미리 봅니다. 이미지를 로컬에서 미리보기하거나 병합 요청의 검토 앱을 사용하여 렌더링된 이미지가 흐릿하거나 압도적이지 않은지 확인합니다.
일관성을 유지합니다. 일관된 읽기 경험을 위해 이미지를 문서 페이지에 이미 있는 기타 이미지와 조율합니다. 네비게이션 테마가 Indigo이고 구문 강조 테마가 Light임을 확인합니다. 이것들이 기본 설정입니다.

부각시키기

스크린샷에서 특정 영역을 강조해야 할 경우, 화살표를 사용합니다.

색상은 #EE2604를 사용합니다. macOS의 미리 보기 앱을 사용하는 경우, 이는 기본 빨간색입니다.
선 두께는 3pt를 사용합니다. macOS의 미리 보기 앱을 사용하는 경우, 이는 목록에서 세 번째 선입니다.
다음 이미지에 표시된 화살표 스타일을 사용합니다.
여러 화살표가 있는 경우 가능한 경우 병렬로 만듭니다.

이미지 저장하기

필요에 따라 넓거나 긴 스크린샷의 크기를 조절하지만, 사진이 조절되고 압축된 후에도 여전히 명확한지 확인합니다.
모든 이미지는 100KB 이하로 압축되어야 합니다. 이미지 품질을 줄이지 않고 25-50KB 이하로 압축하는 경우가 많습니다.
이미지를 해당 이미지의 특징이나 개념을 설명하는 기술적인 이름으로 대문자로 바꾼 뒤 저장합니다:
- 이미지가 GitLab 인터페이스의 경우, 해당 버전에 따라 이미지_이름_vX_Y.png 형식으로 이름을 붙입니다. 예를 들어 GitLab 11.1의 파이프라인 페이지에서 캡처한 스크린샷의 경우, 유효한 이름은 pipelines_v11_1.png입니다.
- 사용자 인터페이스의 일부가 아닌 이미지를 추가하는 경우, 이미지가 추가된 릴리스 번호와 해당하는 릴리스에 대해 추가된 MR의 경우, 유효한 이름은 devops_diagram_v11_1.png입니다.
이미지를 .md 문서가 있는 디렉토리와 동일한 위치에 있는 img/라는 별도의 디렉토리에 저장합니다.
JPEG 대신 PNG 이미지를 사용하는 것을 고려합니다.
GIF 이미지는 https://ezgif.com/optimize 또는 유사한 도구로 압축합니다.
이미지는 프로세스의 설명을 보조하기 위해 (필요할 때만) 사용되어야 하며 대체해서는 안 됩니다.
문서를 설명하는데 비디오를 링크하고 임베드하는 방법도 참고해 주십시오.

이미지 링크를 콘텐츠에 추가하기

문서에 이미지를 포함하는 Markdown 코드는 다음과 같습니다: ![렌더링된 이미지의 대체 텍스트가 될 이미지 설명](img/document_image_title_vX_Y.png)

이미지 설명은 렌더링된 이미지의 대체 텍스트입니다. 접근성과 SEO를 위해 다음과 같은 설명을 사용하세요: - 정확하고 간결하며 고유합니다. - 이미지의 image of 또는 graphic of를 사용하지 마세요.

이미지 압축하기

문서에 추가하는 모든 새 이미지를 항상 압축해야 합니다. 알려진 도구 중 하나는 크로스 플랫폼 오픈 소스인 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)를 사용하지 마세요. 사용자에게 산만하고 귀찮은 경험을 줄 수 있습니다.

사용자 인터페이스의 복잡한 상호 작용을 설명하고 독자가 이해하는 데 시각적 표현을 추가하려면 다음을 사용할 수 있습니다: - 정적 이미지(스크린샷)를 사용하고 필요한 경우 화면의 특정 영역을 강조하기 위해 콜아웃을 추가합니다. - 상호 작용의 짧은 비디오를 만들고 링크를 추가합니다.

자동 스크린샷 생성기

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

GitLab Development Kit (GDK)를 설정합니다.
복제한 GitLab 리포지토리가 있는 하위 디렉터리로 이동합니다(typically gdk/gitlab).
GDK 데이터베이스가 완전히 마이그레이션되었는지 확인하세요: bin/rake db:migrate RAILS_ENV=development.
자세한 정보는 도구 웹사이트에서 확인하세요: pngquant 설치합니다.
scripts/docs_screenshots.rb spec/docs_screenshots/<스크린샷_생성기_이름>.rb를 실행합니다.
스크린샷의 위치를 식별합니다. 스크립트의 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 '<이미지/디렉터리/경로>'
```

여기서 visit <경로>를 사용하여 페이지의 스크린샷을 찍을 수 있습니다. 빈 스크린샷을 피하려면 컨텐츠가 로드될 때까지 기다리도록 expect를 사용하세요.

단일 요소 스크린샷

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

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

screenshot_area = find('<요소>') # 요소 찾기
scroll_to screenshot_area # 요소로 스크롤
expect(screenshot_area).to have_content '<콘텐츠>' # 캡처하려는 콘텐츠 기다리기
set_crop_data(screenshot_area, <여백>) # 추가 여백을 사용하여 요소 캡처

spec/docs_screenshots/container_registry_docs.rb를 사용하여 자체 스크린샷 스크립트를 만드는 데 참고하세요.

Emoji

어떠한 목적으로도 Markdown 이모지 형식(예: :smile:)을 사용하지 마세요. 대신 GitLab SVG 아이콘을 사용하세요.

Markdown에서 이모지를 사용하려면 Kramdown으로 렌더링되는 GitLab 문서에서 지원되지 않는 GitLab Flavored Markdown을 사용해야 합니다.

GitLab SVG 아이콘

GitLab 12.7에서 도입되었습니다.

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

대부분의 경우에는 텍스트에서 아이콘 사용을 피해야 합니다. 그러나 UI 요소를 설명하는 유일한 방법이 호버 텍스트인 경우에는 아이콘을 사용할 수 있습니다. 예를 들어, 삭제 또는 편집 버튼은 종종 호버 텍스트만 가지고 있습니다.

아이콘을 사용할 때는 항상 호버 텍스트로 시작하고 괄호 안에 SVG 참조를 따라야 합니다.

피하세요: **{pencil}** **편집** 선택. 이렇게 작성하면: 편집 선택.
대신 사용: **편집** 선택 (**{pencil}**). 이렇게 작성하면: 편집 선택 ().

아이콘을 설명할 때는 단어를 사용하지 마십시오.

피하세요: **작업 로그 지우기** (휴지통 아이콘).
대신 사용: **작업 로그 삭제** (**{remove}**). 이렇게 작성하면: 작업 로그 삭제 ().

버튼에 호버 텍스트가 없는 경우, 아이콘을 설명할 수 있습니다. 그러고 나서 UX 버그 이슈를 생성하여 버튼에 호버 텍스트를 추가하여 접근성을 향상시킬 수 있습니다.

피하세요: **{ellipsis_v}** 선택.
대신 사용: 수직 탈자 선택 (). 이렇게 작성하면: 수직 탈자 선택 ().

동영상

GitLab YouTube 비디오 튜토리얼을 문서에 추가하는 것이 강력히 권장됩니다. 다만, 비디오가 오래되었을 경우에는 문서를 대체해서는 안 되지만 보완이나 설명을 위해 사용할 수 있습니다. 만약 비디오의 내용이 기능과 주요 사용 사례에 중요하다면서 문서에 충분히 다루어 지지 않는 경우, 다음을 해야 합니다:

이러한 세부 사항을 문서 텍스트에 추가합니다.
해당 비디오를 검토하고 페이지를 업데이트하기 위한 이슈를 생성합니다.

제품 저장소에 비디오를 업로드하지 마십시오. 링크를 제공하거나 임베드 대신 사용하십시오.

비디오 링크

비디오에 링크를 걸 때, 독자들이 보기 전에 페이지를 스캔할 수 있도록 YouTube 아이콘을 포함해야 합니다. 비디오가 오래된 것인지를 확인할 수 있도록 링크 뒤에 비디오의 출판 날짜를 포함해야 합니다.

<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
비디오 제목을 보려면 [비디오 제목](비디오 링크).
<!-- 비디오 출판일 YYYY-MM-DD -->

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

비디오 임베드

GitLab 12.1에서 도입되었습니다.

GitLab 문서 사이트는 임베드된 비디오를 지원합니다.

공식 GitLab YouTube 계정(링크)에서만 비디오를 임베드할 수 있습니다. 다른 소스의 비디오인 경우 링크만 제공하십시오.

대부분의 경우에는 비디오에 링크를 포함하십시오. 임베드된 비디오는 페이지를 많이 차지하여 독자들에게 혼란을 줄 수 있습니다.

비디오를 임베드하기 위해:

이 절차에서 코드를 복사하여 Markdown 파일에 붙여 넣습니다. 위와 아래로 빈 줄을 남겨두십시오 (공백을 제거하거나 추가하지 마십시오).
YouTube에서 표시하려는 비디오 URL을 방문합니다. 브라우저에서 정규 URL(https://www.youtube.com/watch?v=비디오-ID)을 복사하고, 그 URL을 <div class="video-fallback"> 아래의 비디오 제목과 링크를 대체합니다.
YouTube에서 공유을 선택한 다음 임베드을 선택합니다.
<iframe> 소스 (src)의 URL만 복사합니다(https://www.youtube-nocookie.com/embed/비디오-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 문서 사이트에서는 다음과 같이 렌더링됩니다:

비디오: GitLab이란?.

이 형식으로 작성됩니다:

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

클릭 스루 데모에 대한 링크

클릭 스루 데모에 대한 링크는 동영상과 유사한 지침을 따라야 합니다.

클릭 스루 데모는 [데모 제목](데모 링크)에서 확인할 수 있습니다.
<!-- 데모는 YYYY년 MM월 DD일에 공개됨 -->

경고 상자

경고 상자는 정보에 주의를 끌기 위해 사용됩니다. 여러 번 사용하지 말고, 경고 상자 바로 다음에 다른 경고 상자가 오지 않도록 주의하세요.

경고 상자는 다음 단어 뒤에 줄 바꿈이 오면 생성됩니다.

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

예시:

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

경고 상자에 여러 단락, 목록 또는 제목을 표시하려면 블록인용을 대신 사용하세요.

경고 상자는 GitLab 설명서 사이트 (https://docs.gitlab.com)에서만 렌더링됩니다. GitLab 제품 도움말에서는 경고 상자가 일반 텍스트로 표시됩니다.

Flag

기능의 가용성을 설명하는 데 이 경고 유형을 사용합니다. FLAG 경고의 형식에 대한 정보는 기능 플래그 뒤에 배포된 기능 문서를 참조하세요.

Note

주의해서 사용하세요. 너무 많은 주의사항은 주제를 쉽게 샅겨하지 않습니다.

노트를 추가하는 대신:

문장을 다른 단락의 일부로 다시 작성하세요.
정보를 독립된 단락으로 작성하세요.
콘텐츠를 새로운 주제 제목 아래에 두세요.

노트를 사용해야 한다면 다음 형식을 사용하세요:

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

GitLab 설명서 사이트에 다음과 같이 렌더링됩니다:

이것은 주목할 사항입니다.

Warning

폐기된 기능을 표시하거나 데이터 손실 가능성에 대한 경고를 제공하기 위해 경고를 사용하세요.

WARNING:
이것은 경고할 사항입니다.

GitLab 설명서 사이트에 다음과 같이 렌더링됩니다:

이것은 경고할 사항입니다.

Info

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

INFO: 경고의 텍스트는 항상 주변 텍스트의 오른쪽에 부동 상자로 렌더링됩니다. GitLab 설명서 사이트에서 렌더링을 확인하려면 MR의 리뷰 앱을 확인하세요. 부동 상자의 위치에 따라 주변 텍스트를 위로 또는 아래로 이동해야 할 수 있습니다.

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

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

INFO:
다음은 정보입니다. 이 정보는 GitLab과 함께 작업하는 중요한 추가 정보이며 고려할 가치가 있습니다.

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

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

GitLab 설명서 사이트에 다음과 같이 렌더링됩니다:

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

다음은 정보입니다. 이 정보는 GitLab과 함께 작업하는 중요한 추가 정보이며 고려할 가치가 있습니다.

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

Disclaimer

미래 기능에 대해서만 설명하기 위해 사용하세요. 더 많은 정보는 미래 기능을 위한 법적 고지를 참조하세요.

Details

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

Blockquotes

텍스트를 강조하기 위해 블록인용의 이 형식을 사용하세요:

> 이것은 블록인용입니다.

GitLab 설명서 사이트에 다음과 같이 렌더링됩니다:

이것은 블록인용입니다.

텍스트가 여러 줄에 걸칠 경우 각 줄 앞에 > 기호를 사용할 수 있습니다.

여러 단락인 경우 각 라인 앞에 > 기호를 사용하세요:

> 이것은 첫 번째 단락입니다.
>
> 이것은 두 번째 단락입니다.
>
> - 이것은 목록 항목입니다
> - 목록에서 두 번째 항목입니다

GitLab 설명서 사이트에 다음과 같이 렌더링됩니다:

이것은 첫 번째 단락입니다.
이것은 두 번째 단락입니다.

이것은 목록 항목입니다
목록에서 두 번째 항목입니다

탭

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

탭 집합을 만들려면 다음 예제를 따르세요.

::Tabs

:::TabTitle 탭 1

탭 1의 내용입니다.

:::TabTitle 탭 2

탭 2의 다른 내용입니다.

::EndTabs

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

탭 1

탭 1의 내용입니다.

탭 2

탭 2의 다른 내용입니다.

탭 제목은 간결하고 일관되게하십시오. 병렬이어야 하고 각각을 대문자로 시작해야 합니다. 예를 들어:

Linux package (Omnibus), Helm chart (Kubernetes) (구성 편집에 대한 문서화 시, 구성 편집 가이드를 따르세요.)
15.1 and earlier, 15.2 and later

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

자세한 내용은 Pajamas를 참조하세요.

표절

소스가 인용되었음을 명시하는 한 제한된 인용문이 아닌 경우 다른 소스의 내용을 복사하여 붙이지 마십시오. 일반적으로 그 내용을 다시 말하거나 다른 소스에 링크하는 것이 더 나은 방법입니다.

제품 및 기능

GitLab 제품 문서에서 제품 및 기능을 설명할 때는 이 섹션의 정보를 참조하세요.

이름에 줄 바꿈 피하기

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

제품 티어 배지

티어 배지는 특징에 대한 정보를 제공하고 주제 제목 아래에 표시됩니다.

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

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

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

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

티어 배지를 지정하지 마십시오.

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

이 경우 다음 중 하나 또는 모두를 수행하세요:

알림 상자의 NOTE를 사용하여 티어에 대해 설명합니다.
이 정보가 더 의미가 있는 다른 주제 제목 아래에 티어 배지를 추가하십시오.
H1에 티어 배지를 추가하지 마십시오.

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

일부 페이지는 명백한 티어 배지가 적용되지 않으므로 티어 배지가 없습니다. 예를 들어:

튜토리얼.
여러 티어의 기능을 비교하는 페이지.
/development 폴더 안의 페이지. 이러한 페이지는 자동으로 Contribute 배지가 지정됩니다.
/solutions 폴더 안의 페이지. 이러한 페이지는 자동으로 Solutions 배지가 지정됩니다.

사용 가능한 제품 티어 배지

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

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

티어 배지의 Markdown 형식은 다음과 같아야 합니다.

# 주제 제목

세부 정보:
**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

일반적으로 사용 가능한 기능은 상태가 없어야 합니다.

인라인 티어 배지

다른 텍스트와 함께 인라인에 티어 배지를 추가하지 마십시오. 기능의 공식 출처는 기능을 설명하는 주제여야 합니다.

인라인에서 티어를 언급해야 하는 경우 일반 텍스트로 작성하십시오. 예를 들어, API 주제의 경우:

가능한 사용자의 ID. Ultimate 전용.

추가 예제는 REST API 스타일 가이드를 참조하세요.

관리자 문서 티어 배지

인스턴스 관리자 전용 문서는 Self-managed 티어를 가져야 합니다. 인스턴스 관리자 문서에는 종종 다음과 같은 섹션들이 포함되어 있습니다:

gitlab.rb 또는 gitlab.yml 파일 변경.
레일즈 콘솔에 액세스하거나 Rake 작업 실행.
관리자 지역에서 작업 수행.

이러한 페이지는 작업을 실행할 수 있는 사람이 인스턴스 관리자만인 경우에도 언급해야 합니다.

도움 및 피드백 섹션

이 섹션(소개됨 in GitLab 11.4)은 각 문서의 끝에 표시되며, 프론트 매터에 키를 추가하여 생략할 수 있습니다:

---
feedback: false
---

기본값은 표시된 상태를 유지합니다. 문서에서 이를 생략하려면 반드시 기술 작가와 상의해야 합니다.

피드백 섹션의 클릭 이벤트는 Google 태그 매니저로 추적되며, 변환은 Google Analytics에서 행동 > 이벤트 > 상위 이벤트 > docs로 이동하여 볼 수 있습니다.

GitLab 재시작

GitLab을 다시 시작하거나 다시 구성해야 할 때는 여기의 문서에 ‘재구성’을 필요에 맞게 ‘다시 시작’으로 바꾸어 링크를 제공하여 중복을 피하세요:

파일을 저장하고 변경 사항이 적용되도록 GitLab을 [다시 구성](../../../administration/restart_gitlab.md)하세요.

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

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

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

리눅스 패키지
헬름 차트
GitLab 오퍼레이터
도커
자체 컴파일

탭을 사용해서 자체 관리 구성 절차를 설명하는 경우 설명 괄호를 추가하는 것은 괜찮습니다:

리눅스 패키지 (Omnibus)
헬름 차트 (Kubernetes)
GitLab 오퍼레이터 (Kubernetes)
도커
자체 컴파일 (소스)

자체 관리 구성 절차 설명에 탭 사용

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

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

구성 편집을 설명할 때 맘대로 편집할 수 있는 다음 스니펫을 사용하세요:

::Tabs

:::TabTitle 리눅스 패키지 (Omnibus)

1. `/etc/gitlab/gitlab.rb` 파일 편집:

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

1. 파일을 저장하고 GitLab을 다시 구성:

   ```shell
   sudo gitlab-ctl reconfigure
   ```

:::TabTitle 헬름 차트 (Kubernetes)

1. 헬름 값을 내보내기:

   ```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 자체 컴파일 (소스)

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

GitLab X 변경 사항

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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

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

GitLab Helm 차트를 업그레이드하는 자세한 내용은 X.0 릴리스 노트를 참조하세요.

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

일반적인 업그레이드 사항 및 이슈.
…

리눅스 패키지 설치

리눅스 패키지 설치에 대한 특정 정보.
…

직접 컴파일한 설치

직접 컴파일한 설치에 대한 특정 정보.
…

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

Geo에 특정한 정보.
…

X.Y.0

…