• GitLab 어투
• 문서는 단일 정보원(SSoT)
• 주제 유형
• 우선 문서 방법론
• 로컬라이제이션을 위한 작성
• Markdown
  • Markdown에서의 HTML
  • Markdown에서의 제목 수준
  • Markdown에서 백틱 사용
• 언어
  • 능동태
  • 고객 관점
  • 신뢰 구축
  • 대문자 사용
    • 주제 제목
    • UI 텍스트
    • 기능 이름
    • 기타 용어
  • 가짜 사용자 정보
  • 가짜 URL
  • 가짜 토큰
  • 축약형
  • 소유 형태
  • 전치사
  • 약어
  • 숫자
• 텍스트
  • 행 길이
  • 주석
  • 강조
  • 구두점
  • 자리 표시자 텍스트
  • 키보드 명령
  • UI의 버튼
  • UI에 입력된 텍스트
  • 인라인 코드
  • 코드 블록
    • 코드 블록 내의 cURL 명령
• 디렉터리
  • 정렬된 디렉터리 또는 비정렬 디렉터리 선택
  • 디렉터리 마크업
  • 디렉터리 항목 내의 중첩
  • 표 형식 편집기 확장 프로그램
  • 기존 표의 업데이트
  • 표 머리글
  • 기능 표
  • 각주
    • 각주 형식
      • 다섯 개 이상의 각주
• 인용구
• 링크
  • 같은 리포지터리 내에서의 링크
  • 다른 리포지터리의 링크
  • 앵커 링크
    • 링크와 제목 변경
  • 링크 텍스트
    • 표준 텍스트
    • 설명적인 텍스트 사용
    • 이슈에 대한 링크
  • 외부 문서에 대한 링크
  • 비밀 또는 제한된 액세스 링크
  • 코드의 특정 줄에 대한 링크
• 내비게이션
  • 메뉴 이름
  • UI 요소 이름
  • 네비게이션 작업 단계 작성 방법
  • 선택 사항 단계
  • 권장 사항 단계
  • 여러 필드를 문서화하는 방법
• 이미지
  • 이미지 캡처
  • 강조 표시 추가
  • 이미지 저장
  • 이미지 링크 추가
  • 이미지 압축
  • 움직이는 이미지
  • 자동 스크린샷 생성기
    • 도구 확장
      • 단일 요소 스크린샷
• 이모지
• GitLab SVG 아이콘
• 동영상
  • 비디오 링크
  • 비디오 임베드
• 클릭스루 데모에 대한 링크
• 경고상자
  • Flag
  • Note
  • Warning
  • 정보
  • 면책 조항
  • 세부 정보
• 인용 상자
• 탭
• 표절
• 제품 및 기능
  • 이름에 줄 바꿈 피하기
  • 제품 티어 뱃지
    • 언제 티어 뱃지를 추가해야 하는가
    • 언제 티어 뱃지를 추가하지 말아야 하는가
      • 티어 뱃지가 필요 없는 페이지
    • 사용 가능한 제품 등급 뱃지
      • 인라인 등급 뱃지
      • 관리자 문서 등급 뱃지
• 특정 섹션
  • 도움말 및 피드백 섹션
  • GitLab 재시작
  • 다양한 설치 방법 문서화 방법
  • Self-managed 구성 절차 설명에 탭 사용
• X.Y.1 (페이지 상단에 최신 버전 추가)
  • Linux 패키지 설치
  • 직접 컴파일한 설치
  • Geo 설치
• X.Y.0

문서 스타일 가이드

이 문서는 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로 페이지를 렌더링하기 위해 GitLab Kramdown을 사용합니다. Kramdown 기능은 우리의 린터(linter)에 의해 제한되므로, 일반적인 Markdown을 사용하고 링크된 스타일 가이드의 규칙을 따르세요. Kramdown 특정 마크업(예: {:.class})은 사용할 수 없습니다.

완전한 Kramdown 참조는 GitLab Markdown 가이드를 참조하세요.

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

Markdown에서의 HTML

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

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

Markdown에서의 제목 수준

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

• 각 하위 섹션에 대해 제목 수준을 증가시키세요. 다시 말해, 주제 제목 앞의 # 문자 수를 증가시키세요.
• H5(#####)보다 큰 제목 수준은 피하세요. 다섯 개 이상의 제목 수준이 필요한 경우, 대신 해당 주제를 새 페이지로 이동하세요. H5보다 큰 제목 수준은 오른쪽 사이드바 탐색에 표시되지 않습니다.
• 수준을 건너뜁니다. 예: ## > ####.
• 주제 제목 앞 뒤에 한 줄씩 비워 두세요.
• 주제 제목에 코드를 사용하는 경우 코드가 역따옴표 안에 있는지 확인하세요.

Markdown에서 백틱 사용

다음과 같은 경우에 백틱을 사용하십시오:

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

언어

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

• 불필요한 단어를 피합니다.
• 목적에 집중하여 명확하고 간결하게 작성합니다.
• 미국 영어와 미국식 문법으로 작성합니다. (British.yml에서 테스트되었습니다.)

능동태

대부분의 경우 매뉴얼태 대신 능동태를 사용하면 텍스트를 이해하기 쉽고 번역하기 쉽습니다.

예를 들어 다음과 같이 사용합니다:

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

다음과 같이 하지 않습니다:

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

때로는 GitLab을 주체로 사용하는 것이 어색할 수 있습니다. 예를 들어 GitLab이 보고서를 내보냅니다. 이 경우 매뉴얼태를 사용할 수 있습니다. 예를 들어 보고서가 내보내집니다.

고객 관점

고객에게 제공하는 기능 및 이점에 중점을 둡니다.

예를 들어 다음과 같이 사용합니다:

• Merge Request을 사용하여 소스 및 대상 브랜치의 코드를 비교합니다.

다음과 같이 하지 않습니다:

• GitLab을 사용하여 코드를 비교할 수 있습니다.
• GitLab이 코드 비교를 가능하게 만들었습니다.
• Merge Request을 사용하여 코드를 비교할 수 있습니다.

허용 및 가능을 나타내는 단어 대신 당신을 사용하여 사용자에게 직접적으로 말합니다.

신뢰 구축

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

• 쉽게나 간편하게와 같은 단어를 사용하지 않습니다.
• “이 기능은 시간과 비용을 절약해줍니다”와 같은 마케팅 구문을 사용하지 않습니다.

대신 사실과 실현 가능한 목표에 중점을 두세요. 구체적이어야 합니다. 예를 들어:

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

대문자 사용

회사로서 우리는 소문자를 선호합니다.

주제 제목

주제 제목에는 문장 케이스를 사용합니다. 예를 들어:

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

UI 텍스트

버튼 레이블이나 메뉴 항목과 같은 구체적인 사용자 인터페이스 텍스트를 참조할 때, 사용자 인터페이스에 표시된 대문자화를 사용합니다.

사용자 인터페이스 텍스트에 스타일 오류가 있다고 생각되는 경우, 사용자 인터페이스 텍스트에 변경 제안을 하기 위해 이슈 또는 MR을 생성하세요.

기능 이름

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

다만 몇 가지 희귀한 경우에는 기능이 타이틀 케이스가 될 수 있습니다. 이러한 예외 사항은 다음과 같습니다.

• markdownlint에 프로퍼티로 추가되어 일관되게 모든 문서에 적용될 수 있도록 함.
• 단어 디렉터리에 추가됨.

단어 디렉터리에 용어가 포함되지 않은 경우, GitLab 기술 작성자에게 조언을 구하세요.

기본적으로 기능 페이지나 features.yml에서 용어나 구문의 대문자화와 일치시키지 않습니다.

기타 용어

다음을 대문자화합니다:

• GitLab 제품 티어. 예: GitLab Free 및 GitLab Ultimate.
• 타사 조직, 소프트웨어 및 제품. 예: Prometheus, Kubernetes, Git 및 The Linux Foundation.
• 방법 또는 방법론. 예: 지속적 통합, 지속적 배포, 스크럼 및 애자일.

당해하는 기관의 정식 출처에서 규정된 대문자화 스타일을 따르십시오. 이는 비표준 케이스 스타일을 사용할 수 있습니다. 예: GitLab 및 npm.

가짜 사용자 정보

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

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

가짜 URL

문서에 샘플 URL을 포함할 때 다음을 사용합니다:

• 일반적인 도메인 이름인 경우 example.com을 사용합니다.
• Self-managed GitLab 인스턴스만을 참조하는 경우 gitlab.example.com을 사용합니다. GitLab SaaS 인스턴스인 경우 gitlab.com을 사용합니다.

가짜 토큰

cURL을 사용하여 API 호출을 구현하거나 CI에서 사용하는 변수를 보여 주기 위해 가짜 토큰이 필요한 경우가 있을 수 있습니다. 문서에 실제 토큰을 사용하는 것은 감명받을 확률이 낮더라도 강력히 권장되지 않습니다.

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

축약형

축약 문법을 사용하여 친근하고 비공식적인 분위기를 조성할 수 있습니다. 특히 자습서, 교육용 문서 및 사용자 인터페이스의 경우에 해당합니다.

그러나 일부 축약 양식은 피해야 합니다.

소유 형태

조직명 또는 제품명과 같은 고유명사에 대해 소유형 ('s) 사용을 피하십시오.

예를 들어 Docker's CLI 대신 the Docker CLI를 사용하세요.

자세한 내용은 Google 문서 스타일 가이드를 참조하세요.

전치사

문장 끝에 필요한 경우 전치사를 사용하세요. 매달린 또는 오류로 이어진 전치사는 괜찮습니다. 예를 들어:

• You can leave the group you’re a member of.
• Share the credentials with users you want to give access to.

이러한 양식은 대안에 비해 더 친밀성을 띄고 있습니다:

• You can leave the group of which you’re a member.
• Share the credentials with users to which you want to give access.

약어

약어를 사용하는 경우, 페이지 최초 사용시 풀어서 쓰세요. 페이지 내에서 한 번 이상 풀어쓸 필요는 없습니다.

• 제목: 특히 약어가 널리 사용되지 않는 경우에는 주제 제목에서 약어 사용을 피하십시오.
• 복수형: 약어를 복수형으로 사용하지 마세요. 예를 들어 YAML files 대신 YAMLs를 사용하지 마세요. 반드시 약어를 복수형으로 만들어야 하는 경우에는, 아포스트로피를 사용하지 마세요. 예를 들어 APIs 대신 API's를 사용하지 마세요.
• 소유형: 약어를 소유형으로 만드는 경우 주의하세요. 가능하다면 약어를 소유형으로 만들지 않도록 문장을 작성하세요. 반드시 약어를 소유형으로 만들어야 하는 경우, 전체 단어를 풀어서 쓰는 것을 고려하세요.

숫자

텍스트 내 숫자를 작성할 때는 0부터 9까지는 숫자로 적고, 10 이상은 숫자로 적으세요. 자세한 내용은 Microsoft Style Guide를 참조하세요.

텍스트

• 마크다운으로 작성하세요.
• 새 단락을 위해 빈 줄을 삽입하세요.

• 서로 다른 마크업 사이에는 빈 줄을 삽입하세요(예: 단락 뒤, 제목 뒤, 디렉터리 뒤 등). 예시:

  ## 제목
    
  단락.
    
  - 디렉터리 항목 1
  - 디렉터리 항목 2
  

행 길이

소스 내용을 쉽게 읽고 차이를 비교하기 쉽도록 만들기 위해 가능한 경우 이러한 모범 사례를 따르세요.

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

주석

Markdown 내에서 주석을 삽입하려면 게시될 때 렌더링되지 않는 일반 HTML 주석을 사용하세요. 예시:

<!-- This is a comment that is not rendered -->

강조

강조를 표현할 때 기울임꼴 대신 굵은체를 사용하세요. GitLab은 산세리프 글꼴을 사용하며 이탤릭체는 세리프 글꼴에서처럼 두드러지지 않습니다. 자세한 내용은 Butterick’s Practical Typography guide on bold or italic를 참조하세요.

항목을 소개할 때는 이탤릭을 사용할 수 있습니다. 그 외에는 굵은글씨를 사용하세요.

• 굵게 표시하려면 두 개의 별표(**)를 사용하세요 (**굵은체**).
• 이탤릭체로 나타내려면 밑줄(_)을 사용하세요 (_이탤릭체_).
• 인용구로 나타내려면 크다라기표(>)를 사용하세요.

구두점

다음과 같이 구두점에 대한 지침을 따르세요.

• 마침표로 완전한 문장을 끝내세요. 표 안에 완전한 문장도 마침표를 사용하세요.
• 세계의 과 또는 또는으로 연결된 항목이 세 개 이상인 디렉터리에서는 맨 마지막 항목 앞에 시리얼(Oxford) 쉼표를 사용하세요. (‘OxfordComma.yml’에서 테스트됨).

내용 공간을 띄울 때:

• 문장 사이에 한 칸의 간격을 사용하세요. (한 칸 이상의 간격 사용 여부는 ‘SentenceSpacing.yml’에서 테스트됨).
• 줄 바꿈에 준하는 공백 문자를 사용하지 마세요. 일반 공백을 사용하세요. (‘lint-doc.sh’에서 테스트됨).

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

• ; (세미콜론): 두 개의 문장을 사용하세요.
• – (엔 대시) 또는 — (엠 대시): 별개의 문장이나 쉼표를 사용하세요.
• “ ” ‘ ’: 곡선 인용 부호를 사용하지 마세요. 곧은 따옴표를 사용하세요.(‘NonStandardQuotes.yml’에서 테스트됨).

자리 표시자 텍스트

코드 블록에서 특정 값으로 바꾸어야 하는 명령 또는 구성을 제공할 수 있습니다.

이런 경우, 독자가 텍스트를 자신의 값으로 바꿔야 하는 부분을 < 와 >으로 표시하세요.

예를 들어:

cp <your_source_directory> <your_destination_directory>

플레이스홀더가 코드 블록에 없는 경우 < 와 >를 사용하고 플레이스홀더를 하나의 역따옴표로 감싸세요. 예시:

Select **Grant admin consent for `<application_name>`**.

키보드 명령

HTML <kbd> 태그를 사용하여 키를 누르는 것을 참조할 때 사용합니다. 예를 들어:

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

문서가 생성되면 출력은 다음과 같습니다:

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

UI의 버튼

가시적 레이블이 있는 요소의 경우 해당 레이블을 굵게 표시합니다.

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

UI에 입력된 텍스트

UI에서 사용자가 무언가를 입력하도록 원하는 경우 백틱을 사용합니다. 예를 들어:

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

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

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

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

인라인 코드

인라인 코드 스타일은 일반 텍스트와 함께 적용됩니다. 다음과 같은 경우 인라인 코드 스타일을 사용합니다.

• 파일 이름 또는 구성 파일 조각에 대해. 예를 들어, .gitlab-ci.yml, CODEOWNERS, only: [main].
• HTTP 메서드 (HTTP POST) 및 HTTP 상태 코드, 전체 (404 파일을 찾을 수 없음) 및 약어 (404)에 대해 사용합니다. 예를 들어: 러너를 삭제하려면 DELETE 요청을 보냅니다. 하나를 만들려면 POST 요청을 보냅니다.

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

코드 블록

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

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

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

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

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

코드 블록 내의 cURL 명령

cURL 명령에 대한 정보는 cURL 명령을 참조하세요.

디렉터리

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

• 디렉터리의 항목은 모두 병렬해야 합니다. 예를 들어 몇몇 점에는 명사로, 다른 몇몇은 동사로 시작하지 말아야 합니다.
• 문구가 완전한 문장이 아닌 경우 마침표를 사용하지 마세요.
• 모든 항목에 마침표를 사용하세요. 세미콜론이나 쉼표를 사용하지 마세요.
• 모든 항목을 동일한 구두점으로 지정하세요.
• 모든 항목을 대문자로 시작하세요.

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

  다음을 할 수 있습니다:
    
  - 이 작업을 수행하세요.
  - 다른 작업을 수행하세요.
  

정렬된 디렉터리 또는 비정렬 디렉터리 선택

단계의 연속성이 있는 경우 정렬된 디렉터리을 사용하세요. 예를 들어:

무언가를 수행하려면 다음 단계를 따르세요.

1. 처음에 첫 번째 단계를 수행하세요.
1. 그런 다음 다음 단계를 수행하세요.
1. 마지막으로 마지막 단계를 수행하세요.

단계를 순서대로 수행할 필요가 없는 경우 비정렬 디렉터리을 사용하세요. 예를 들어:

다음 항목이 가져와졌습니다:

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

디렉터리 마크업

비정렬 디렉터리에는 별표(*) 대신 대시(-)를 사용하세요. 정렬된 디렉터리의 모든 항목을 1.로 시작하세요. 렌더링되면 디렉터리 항목이 순차적으로 표시됩니다. 디렉터리 앞뒤로 빈 줄을 남겨주세요. 들여쓰기된 하위 항목을 표시하려면 줄을 시작할 때 공백(탭이 아님)을 사용하여야 합니다.

디렉터리 항목 내의 중첩

리스트 항목 아래에 항목을 중첩해서 배치할 수 있으므로 동일한 들여쓰기로 렌더링됩니다. 이는 다음과 같은 항목에 적용할 수 있습니다.

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

중첩된 항목은 항상 디렉터리 항목의 첫 문자와 일치하도록 해야 합니다. 비정렬 디렉터리(대시(-) 사용)의 경우 각 수준의 들여쓰기에 두 개의 공백을 사용하세요.

- 비정렬된 디렉터리 항목 1
  
  `U`와 일치하도록 공간 2개를 사용하여 들여쓴 줄.

- 비정렬된 디렉터리 항목 2
  
  > 디렉터리 항목 2에 중첩될 인용 블록
  > 
  >   블록 안에 새줄을 추가할 수 있습니다.
  >   새로운 줄입니다.

- 비정렬된 디렉터리 항목 3
  
  ```plaintext
  디렉터리 항목 3 내에 중첩된 코드 블록입니다.
  ```

- 비정렬된 디렉터리 항목 4
  
  ![디렉터리 항목 4에 중첩될 이미지](image.png)

정렬된 디렉터리의 경우 각 수준의 들여쓰기에 세 개의 공백을 사용하세요.

1. 정렬된 디렉터리 항목 1
   
   `O`와 일치하도록 공간 3개를 사용하여 들여쓴 줄.

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

1. 정렬 디렉터리 항목 첫 번째.
1. 정렬 디렉터리 항목 두 번째.
   - 중첩된 비정렬 디렉터리 항목 첫 번째.
   - 중첩된 비정렬 디렉터리 항목 두 번째.
1. 정렬 디렉터리 항목 세 번째.

- 비정렬 디렉터리 항목 첫 번째.
- 비정렬 디렉터리 항목 두 번째.
  1. 중첩된 정렬 디렉터리 항목 첫 번째.
  1. 중첩된 정렬 디렉터리 항목 두 번째.
- 비정렬 디렉터리 항목 세 번째.
  
## 표

표는 복잡한 정보를 직관적으로 설명하는 데 사용되어야 합니다. 많은 경우 각 항목에 대해 단일하고 간단한 설명을 제공하는 비정렬 디렉터리이 충분합니다. 하지만 행렬로 설명하는 데이터가 최적인 경우 표를 사용하세요.

### 생성 가이드라인

표가 쉽게 이해하고 쉽게 스캔할 수 있도록 빈 셀이 없어야 합니다. 셀에 의미 있는 값이 없는 경우 "N/A" (해당 없음) 또는 "None"을 입력하는 것을 고려해보세요.

표를 더 쉽게 유지하려면 다음을 할 수 있습니다.

- 열 너비를 일관되게 만들기 위해 추가 공간을 추가할 수 있습니다. 예를 들어:
  
  ```markdown
  | 앱 이름 | 설명             | 요구 사항      |
  |---------|------------------|---------------|
  | 앱 1    | 설명 텍스트 1.    | A, B 및 C     |
  | 앱 2    | 설명 텍스트 2.    | 해당 없음     |

• 매우 넓은 표의 경우 오른쪽 열의 추가 공간을 건너뛸 수 있습니다. 예를 들어:

  | 설정       | 기본값 | 설명                                |
  |-----------|-------|-------------------------------------|
  | 설정 1    | `1000`| 간단한 설명                        |
  | 설정 2    | `2000`| 표가 너무 넓어지고 많은 공백을 추가하면 이 열에 있는 모든 셀을 정렬하면 최종 요약을 알려주는 너무 넓은 설명.|
  | 설정 3    | `0`   | 다른 간단한 설명                    |
  

표 형식 편집기 확장 프로그램

모든 Markdown 파일에서 일관된 표 형식을 보장하려면 테이블을 VS Code Markdown Table Formatter로 서식 지정하는 것을 고려해보세요. 위의 가이드라인을 따르도록 이 확장 프로그램을 구성하려면 헤더 행 길이 따르기 설정을 활성화하세요. 설정을 활성화하려면:

• UI에서:

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

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

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

이 확장 프로그램을 사용하여 표를 서식 지정하려면 전체 표를 선택한 후 마우스 오른쪽 단추를 클릭하고 `다음으로 선택 모양 서식 지정을 선택하세요. VS Code 명령 팔레트에서 Markdown Table Formatter를 선택하세요.

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

기존 표의 업데이트

기존 표에 행을 추가하거나 수정할 때 새 행의 셀이 더 넓을 수 있습니다. 너비를 고려하여 열을 재조정하면 전체 표가 수정된 것으로 표시되어 diff를 읽기가 어려워집니다.

Markdown 표는 시간이 지남에 따라 자연스럽게 정렬이 풀릴 수 있지만 docs.gitlab.com에서는 여전히 올바르게 렌더링됩니다. 기술 문서 팀은 페이지를 재구성할 때 다음에 셀을 재정렬할 수 있습니다.

표 머리글

표 머리글에는 문장 표기를 사용하세요. 예를 들어 키워드 값 또는 프로젝트 이름과 같이요.

기능 표

기능의 디렉터리을 표로 만들 때(예: 권한 페이지의 각 권한에 대한 가능한 기능), 다음 구문을 사용하세요:

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

각주

표 아래에 내용을 표 자체에 포함할 수 없을 때에만 각주를 사용하세요. 예를 들면, 동일한 정보를 여러 표 셀에 제공해야 하는 경우나 표의 레이아웃을 방해할 수 있는 내용을 포함해야 하는 경우에 각주를 사용하세요.

각주 형식

표 안에서 각 주석에 HTML 윗첨자 태그 <sup>을 사용하세요. 태그는 마침표 뒤에 사용하세요.

예를 들면:

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

각주를 추가할 때 기존 태그를 재정렬하지 마세요.

표 아래에 각주를 추가할 때, 각주: 다음에 순서가 매겨진 디렉터리을 사용하세요.

예를 들면:

**각주:**


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

위의 표와 각주는 다음과 같이 렌더링됩니다:

각주:

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

다섯 개 이상의 각주

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

**각주:**


<!-- Markdown 규칙 'https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md029---ordered-list-item-prefix' 비활성화 -->
<!-- markdownlint-disable MD029 -->

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

<!-- markdownlint-enable MD029 -->

인용구

Markdown 콘텐츠에 대해서만 유효하며, 프론트 매터 항목에는 해당하지 않습니다:

• 표준 인용구: 큰따옴표("). 예: “이것은 큰따옴표로 감싸여 있습니다”.
• 인용구 내의 인용구: 큰따옴표(")로 작은따옴표(')를 감쌉니다. 예: “이 문장은 ‘인용문’ 내의 내용을 인용합니다”.

기타 구두점 규칙에 대해서는 Pajamas 디자인 시스템 구두점 섹션을 참고하세요. 이 규칙은 문서별 구두점 규칙에 의해 재정의됩니다.

링크

링크는 문서가 진리의 단일 소스에 일치하도록 도와줍니다.

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

• 동일한 페이지에서 링크를 중복해서 넣지 마세요. 예를 들어 페이지 A에서 페이지 B로 여러 번 링크를 걸지 마세요.
• 하나의 단락에 여러 개의 링크를 피하세요.
• 한 번에 한 페이지에서 다른 페이지로의 링크를 15개 이상 사용하지 마세요.
• 작업 단위 내에서 여러 링크를 사용하지 마세요.
• 작업에 차질이 생기는 링크를 줄이기 위해 관련 주제를 사용하는 것을 고려하세요.
• 같은 리포지터리의 섹션에 대한 앵커 링크는 피하세요. 사용자가 올바른 탐색을 의지할 수 있도록 하세요.

같은 리포지터리 내에서의 링크

동일 리포지터리의 다른 페이지에 링크하려면 상대 파일 경로를 사용하세요. 예를 들어, ../user/gitlab_com/index.md와 같이 사용하세요.

참조 스타일 링크가 아닌 Text와 같은 인라인 링크 Markdown 마크업을 사용하세요.

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

다른 리포지터리의 링크

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

앵커 링크

각 주제 제목에는 앵커 링크가 있습니다. 예를 들어 제목이 ## 예제입니다인 주제는 앵커 #example-입니다를 가지고 있습니다.

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

Kramdown을 사용하면 HTML 요소에 사용자 정의 ID를 추가할 수 있지만, 이러한 ID는 /help에서 작동하지 않으므로 사용하지 말아야 합니다.

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

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

링크와 제목 변경

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

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

이러한 링크를 수정하지 않으면 Merge Request에서의 ui-docs-lint 작업이 실패합니다.

링크 텍스트

링크 텍스트에 대한 지침을 다음과 같이 따르세요.

표준 텍스트

가능한 경우 다음 패턴 중 하나를 따르는 텍스트를 사용하세요.

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

예를 들어:

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

이러한 텍스트를 확장하여 “이 기능에 대한 자세한 내용은 다음을 참조하세요…”와 같은 구문을 사용할 수 있습니다.

다음과 같은 구문을 사용하지 마세요:

• 더 알아보기…
• 자세히 읽기….
• 자세한 정보는 [Merge Request](LINK) 페이지를 참조하세요.
• 자세한 정보는 [Merge Request](LINK) 문서를 참조하세요.

설명적인 텍스트 사용

링크에는 여기나 이 페이지와 같은 단어 대신에 설명적인 텍스트를 사용하세요.

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

• 자세한 내용은 [Merge Request](LINK)을 참조하세요.

이슈에 대한 링크

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

• 자세한 내용은 [이슈 12345](LINK)을 참조하세요.

왼쪽 제목에는 파운드(이슈#12345) 기호를 사용하지 마세요.

외부 문서에 대한 링크

가능한 경우 외부 문서에 대한 링크를 피하세요. 이러한 링크는 쉽게 오래된 링크가 되고 유지 관리가 어려워질 수 있습니다.

• 링크가 부서집니다(Link rot)
• 유지 관리에 문제를 일으킵니다.

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

추가하는 각 외부 링크에 대해 고객 이익과 유지 보수의 어려움을 따져보세요.

비밀 또는 제한된 액세스 링크

다음에 직접 링크를 걸지 마세요:

• 비밀 이슈.
• 내부 핸드북 페이지.
• 특정 권한이 필요한 프로젝트 기능을보려면 특별한 권한이 필요합니다.

이러한 링크는 충분한 권한이 없는 사람들에게 실패합니다. 자동화된 링크 확인기.

이러한 링크 중 하나를 사용해야 한다면:

• 링크가 비밀 이슈 또는 내부 핸드북 페이지로 이동한다면 그 문제나 페이지가 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 UI 탐색에 대해 문서화할 때 다음을 따르세요:

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

메뉴 이름

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

• 왼쪽 사이드바: 이것은 사용자 인터페이스의 왼쪽에있는 탐색 사이드바입니다.
  • context switcher 또는 switch contexts라는 구문을 사용하지 마세요. 대신 일련의 반복 가능한 단계로 사용자를 정확한 위치로 안내하려고 노력하세요.
  • 탐색 메뉴 또는 내 작업 사이드바를 사용하지 마세요. 대신 왼쪽 사이드바를 사용하세요.
• 오른쪽 사이드바: 이것은 열린 이슈, Merge Request 또는 이픽에 특정한 사용자 인터페이스 오른쪽에있는 탐색 사이드바입니다.

UI 요소 이름

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

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

일관성을 유지하려면 다음 예제를 사용하여 작업 주제의 네비게이션 단계를 작성하세요. 대체 단계가 가능한 경우 여러분이 기본적으로 고정된 항목을 포함하면서 아래의 단계를 사용하세요.

프로젝트 설정을 열려면:

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

그룹 설정을 열려면:

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

프로젝트 또는 그룹 설정을 열려면:

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

프로젝트를 만들려면:

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

그룹을 만들려면:

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

Admin Area를 열려면:

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

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

당신의 작업 메뉼 항목을 선택하려면:

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

아바타를 선택하려면:

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

일부 드롭다운 디렉터리에서 선택을 저장하려면:

1. 당신의 이슈로 이동합니다.
1. 오른쪽 사이드바에서 **이터레이션** 섹션에서 **편집**을 선택합니다.
1. 드롭다운 디렉터리에서 이 이슈와 연결할 이터레이션을 선택합니다.
1. 드롭다운 디렉터리 외부 영역을 선택합니다.

모든 프로젝트를 보려면:

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

모든 그룹을 보려면:

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

선택 사항 단계

단계가 선택 사항인 경우, 해당 단계는 ‘Optional’이라는 단어로 시작하고 마침표를 찍습니다.

예시:

1. Optional. 작업에 대한 설명을 입력하십시오.

권장 사항 단계

단계가 권장되는 경우, 해당 단계는 ‘Recommended’라는 단어로 시작하고 마침표를 찍습니다.

예시:

1. Recommended. 작업에 대한 설명을 입력하십시오.

여러 필드를 문서화하는 방법

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

필드 작성이라는 구문을 사용하세요.

예시:

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

여러 필드에 대한 설명을 하려면, 정렬되지 않은 디렉터리 항목을 사용하세요:

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

이미지

이미지는 컨셉을 이해하는 데 도움이 될 수 있기 때문에 독자가 더 잘 이해할 수 있도록 도움이 됩니다. 그러나:

• 이미지는 쉽게 오래되기 마련입니다.
• 로컬라이징하기 어렵고 비싸기 때문에 이미지는 중도에서 자제해야 합니다.
• 스크린 리더가 이미지를 읽을 수 없습니다.

필요한 경우 독자가 다음을 이해할 수 있도록 이미지를 사용하세요:

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

이미지 캡처

스크린샷을 찍을 때:

• 정보를 제공할 수 있도록 보장합니다. lorem ipsum 텍스트를 사용하지 마십시오. 실제 사용 시나리오에서 해당 기능이 어떻게 사용될지 복제하고 현실적인 텍스트를 사용하십시오.
• 관련된 UI만 캡처합니다. 불필요한 공백이나 포인트를 설명하지 않는 UI 영역은 포함하지 마십시오. GitLab의 사이드바가 변할 수 있으므로 필요한 경우를 제외하고 사이드바를 포함하지 마십시오.
• 크기를 작게 유지합니다. 전체 화면 너비를 보여줄 필요가 없다면 보여주지 마십시오. 요소들이 가깝게 유지되고 빈 공간이 줄어들도록 브라우저 창의 크기를 줄입니다. 스크린샷 크기를 가능한 한 작게 유지하십시오.
• 페이지에 이미지가 어떻게 렌더링되는지 확인합니다. 이미지를 로컬에서 미리보기하거나 MR의 리뷰 앱을 사용하여 확인합니다. 이미지가 흐릿하거나 과도하게 크지 않은지 확인합니다.
• 일관성을 유지합니다. 일관된 읽기 경험을 위해 문서 페이지에 이미지를 조율합니다. 탐색 테마가 Indigo이고 구문 강조 테마가 Light임을 확인합니다. 이것이 기본 설정입니다.

강조 표시 추가

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

• 색상으로 #EE2604를 사용합니다. macOS의 미리보기 앱을 사용하는 경우, 이것은 기본 빨강입니다.
• 선의 너비로 3 pt를 사용합니다. macOS의 미리보기 앱을 사용하는 경우, 이것은 디렉터리에서 3번째 선입니다.
• 다음 이미지에 표시된 화살표 스타일을 사용합니다.
• 여러 개의 화살표가 있는 경우 가능하면 평행하게 만듭니다.

이미지 저장

• 넓거나 긴 스크린샷을 크기 조정하되, 화면샷이 크기를 줄인 후에도 여전히 선명한지 확인합니다.
• 모든 이미지는 100KB 또는 그 이하로 압축되어야 합니다. 많은 경우, 이미지 품질을 줄이지 않고 25-50KB 이하로 줄이는 것이 가능합니다.
• 이미지를 설명하는 데 사용되는 기능이나 개념을 설명하는데 적합한 소문자 파일 이름으로 저장합니다:
  • 이미지가 GitLab 인터페이스의 일부인 경우, 다음 형식에 따라 이미지 이름에 GitLab 버전을 추가합니다: image_name_vX_Y.png. 예를 들어, GitLab 11.1의 파이프라인 페이지에서 캡처한 스크린샷의 유효한 이름은 pipelines_v11_1.png입니다.
  • 사용자 인터페이스의 일부가 아닌 그림을 추가하는 경우, 그림이 추가된 릴리스 번호에 해당하는 릴리스 번호를 추가합니다. 11.1의 마일스톤에 추가 된 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) 사용을 피하세요. 사용자들에게 혼란스럽고 귀찮을 수 있습니다.

UI의 복잡한 상호 작용을 설명하고 독자가 이해하는 데 도움을 주기 위해 시각적 표현물을 포함하려면 다음을 사용할 수 있습니다:

• 정적 이미지(스크린샷) 사용하고 필요한 경우 화면 영역을 강조하기 위해 콜아웃 추가.
• 상호 작용을 설명하는 짧은 동영상 만들고 이에 링크 걸기.

자동 스크린샷 생성기

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

1. GitLab 개발 키트 (GDK)를 설정하세요.
2. 복제한 GitLab 리포지터리의 하위 디렉터리인 일반적으로 gdk/gitlab로 이동하세요.
3. GDK 데이터베이스가 완전히 마이그레이션되었는지 확인하세요: bin/rake db:migrate RAILS_ENV=development.
4. pngquant 설치하고 자세한 정보는 도구 웹사이트를 참조하세요: pngquant
5. scripts/docs_screenshots.rb spec/docs_screenshots/<스크린샷_생성기_이름>.rb <마일스톤-버전> 실행하세요.
6. 스크린샷의 위치는 스크립트에서 it 매개변수로 정의된 gitlab/doc 위치를 기반으로 식별하세요.
7. 새로 생성된 스크린샷을 커밋하세요.

도구 확장

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

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

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

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

3. 각 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를 참조하여 직접 스크립트를 만드세요.

이모지

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

Markdown에서 이모지 사용은 지원되지 않는 Kramdown을 사용하는 GitLab 문서에서 지원되지 않습니다.

GitLab SVG 아이콘

• GitLab 12.7에서 도입.

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

대부분의 경우 텍스트에서 아이콘 사용을 피해야 합니다. 그러나 삭제 또는 편집 버튼과 같이 활버 텍스트가 유일한 설명 방법인 경우 아이콘을 사용할 수 있습니다. 예를 들어, 다음과 같이 사용하세요: 편집 ().

아이콘을 사용할 때 아이콘을 설명하는 단어를 사용하지 마세요.

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

버튼에 활추 텍스트가 없는 경우 아이콘을 설명할 수 있습니다. 이후 접근성을 향상시키기 위해 UX 버그 이슈를 생성하세요.

• 피하세요: **{ellipsis_v}** 선택.
• 대신 사용하세요: 수직 닷 메뉴 선택 (**{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 계정에서만 비디오를 임베드할 수 있습니다. 다른 출처의 비디오의 경우 링크만 제공하세요.

대부분의 경우, 페이지 공간을 많이 차지하고 독자의 주의를 산만하게 할 수 있기 때문에 임베드된 비디오 대신 비디오에 대한 링크를 제공하세요.

비디오를 임베드하려면:

1. 이 절차에서 코드를 복사하여 Markdown 파일에 붙여넣으세요. 위와 아래에 빈 줄을 남겨두세요. 코드를 편집하지 마세요(공백을 삭제하거나 추가하지 마세요).
2. YouTube에서 표시하려는 비디오 URL을 방문하세요. 브라우저에서 정규 URL을 복사하세요 (https://www.youtube.com/watch?v=VIDEO-ID) 그리고 <div class="video-fallback"> 아래의 비디오 제목과 링크를 대체하세요.
3. YouTube에서 공유을 선택하고 임베드를 선택하세요.
4. <iframe> 소스(src)(URL만)를 복사하세요 (https://www.youtube-nocookie.com/embed/VIDEO-ID) 그리고 iframe 태그의 src 필드 내용을 대체하세요.
5. 비디오의 게시일을 링크 아래에 포함하여 오래된 비디오를 식별하는 데 도움이 되도록 해야 합니다.

여기에 빈 줄을 남겨두세요
<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 문서 사이트에서는 다음과 같이 렌더링됩니다:

이렇게 서식을 지정하면:

• figure 태그는 의미론적 SEO에 필요하며 video-container 클래스는 다양한 모바일 기기에서 비디오가 반응형으로 표시되도록 하는 데 필요합니다.
• video-fallback은 GitLab Markdown 프로세서가 iframe을 지원하지 않기 때문에 /help에서만 표시되는 보조 수단입니다. 문서 사이트에서는 숨겨지지만 /help에서 표시됩니다.
• www.youtube-nocookie.com 도메인은 YouTube 임베드 플레이어의 Privacy Enhanced Mode를 가능하게 합니다. 이 모드를 사용하면 제한된 쿠키 환경에서도 임베드된 비디오를 볼 수 있습니다.

클릭스루 데모에 대한 링크

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

클릭스루 데모를 보려면 [데모 제목](데모-링크)를 참조하세요.
<!-- 데모 게시일: YYYY년-MM월-DD일 -->

경고상자

경고상자를 사용하여 정보에 대한 주의를 요청하세요. 경고상자를 사용은 삼가고 경고상자가 직후에 다른 경고상자가 나타나지 않도록 하세요.

라인 브레이크에 다음 단어 중 하나가 뒤따르는 경우 경고상자가 생성됩니다:

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

예를 들어:

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

여러 단락, 디렉터리 또는 제목에 대한 경고상자를 표시하려면, blockquotes를 대신 사용하세요.

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

Flag

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

Note

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

노트를 추가하는 대신:

• 문장을 단락의 일부로 다시 작성하세요.
• 내용을 별도의 단락으로 정리하세요.
• 내용을 새로운 주제 제목 아래에 넣으세요.

노트를 사용해야 하는 경우 다음 형식을 사용하세요:

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

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

Warning

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

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

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

정보

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

INFO: 알림의 텍스트는 항상 주변 텍스트의 오른쪽에 부유하는 텍스트 상자로 렌더링됩니다. GitLab docs 사이트를 보려면 MR의 검토 앱을 확인하세요. 부유 상자가 나타나기를 원하는 위치에 따라 텍스트를 위로 또는 아래로 이동해야 할 수도 있습니다.

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

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

INFO:
여기에 일부 정보가 있습니다. 이 정보는 GitLab과 작업하는 방식에 중요한 추가 사항이며 고려할 가치가 있습니다.

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

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

GitLab 문서 사이트에 렌더링된 것:

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

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

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

면책 조항

미래 기능을 설명하는 데 사용합니다. 자세한 정보는 Legal disclaimer for future features을 참조하세요.

세부 정보

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

인용 상자

인용 텍스트를 강조하려면 다음 형식을 사용하세요:

> 이것은 인용문입니다.

GitLab 문서 사이트에 렌더링된 것:

이것은 인용문입니다.

글이 여러 줄로 이어지는 경우 이들을 나눌 수 있습니다.

여러 단락을 위해 각 줄 앞에 > 기호를 사용하세요:

> 이것은 첫 번째 단락입니다.
>
> 이것은 두 번째 단락입니다.
>
> - 이것은 디렉터리 항목입니다
> - 디렉터리의 두 번째 항목

GitLab 문서 사이트에 렌더링된 것:

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

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

• 이것은 디렉터리 항목입니다
• 디렉터리의 두 번째 항목

탭

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

탭 세트를 만들려면 이 예시를 따르세요:

::Tabs

::Tabs 1

여기에 탭 1의 콘텐츠가 있습니다.

::Tabs 2

여기에 탭 2의 다른 콘텐츠가 있습니다.

::EndTabs

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

탭 제목은 간결하고 일관되도록 하세요. 병렬이 되도록 하고 모든 시작을 대문자로 시작하는 것을 확인하세요.

예를 들어:

• Linux 패키지 (Omnibus), Helm 차트 (Kubernetes) (구성 편집을 문서화할 때는 구성 편집 가이드를 따르세요)
• 15.1 및 이전, 15.2 및 이후

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

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

표절

소스를 인용하여 유한한 인용이 아닌 경우 다른 곳에서 내용을 복사하여 붙여넣지 마세요. 일반적으로 관련 정보를 여러분의 말로 다시 표현하거나 다른 소스로 연결하는 것이 더 좋습니다.

제품 및 기능

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

이름에 줄 바꿈 피하기

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

제품 티어 뱃지

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

언제 티어 뱃지를 추가해야 하는가

다음에 티어 뱃지를 할당하세요.

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

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

언제 티어 뱃지를 추가하지 말아야 하는가

티어 뱃지를 할당하지 마세요:

• 기능이 하나의 명백한 구독 티어나 제공에 해당하지 않는 경우. 예를 들어, 기능이 SaaS의 하나의 티어에 적용되고 Self-managed의 다른 티어에 적용되는 경우.

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

• 가이드 안내 상자에서 NOTE를 사용하여 티어에 대한 설명을 제공합니다.
• 이 정보가 더 의미가 있는 다른 주제 제목 아래에 티어 뱃지를 추가합니다.
• H1 아래에 티어 뱃지를 추가하지 마세요.

티어 뱃지가 필요 없는 페이지

일부 페이지에는 명백한 티어 뱃지가 적용되지 않기 때문에 티어 뱃지가 없을 수 있습니다. 예를 들어:

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

사용 가능한 제품 등급 뱃지

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

등급 뱃지에는 등급, 오퍼링, 상태 및 이력이 포함됩니다.

등급 뱃지의 마크다운은 다음과 같아야 합니다:

# 주제 제목

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

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

인라인 등급 뱃지

다른 텍스트와 함께 등급 뱃지를 추가하지 마세요. 기능에 대한 유일한 출처는 기능이 설명된 주제여야 합니다.

인라인에서 등급을 언급해야 하는 경우 일반 텍스트로 작성하세요. 예:

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

더 많은 예제는 REST API style guide를 참조하세요.

관리자 문서 등급 뱃지

인스턴스 관리자 전용인 주제는 Self-managed 등급이어야 합니다. 인스턴스 관리자 문서에는 종종 다음을 언급하는 섹션들이 포함됩니다:

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

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

특정 섹션

특정 섹션에는 특정한 스타일이 적용되어야 합니다. 특정 섹션의 스타일은 이 섹션에 개요가 되어 있습니다.

도움말 및 피드백 섹션

이 섹션(GitLab 11.4에서 도입됨)은 각 문서의 끝에 표시되며, 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 systemctl restart gitlab.target
   ```

::EndTabs

GitLab X 변경 사항

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

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

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

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

• 일반적인 업그레이드 노트 및 문제점.
• …

Linux 패키지 설치

• Linux 패키지 설치에 대한 특정 정보.
• …

직접 컴파일한 설치

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

Geo 설치

• Geo에 특정한 정보.
• …

X.Y.0

…