개발 스타일 가이드

에디터/IDE 스타일 표준화

우리는 EditorConfig를 사용하여 파일이 로컬로 저장되기 전에 특정 스타일 표준을 자동으로 적용합니다.

일부 에디터와 IDE는 기본적으로 .editorconfig 설정을 자동으로 지원합니다.

만약 당신의 에디터나 IDE가 .editorconfig를 자동으로 지원하지 않는다면, 플러그인이 존재하는지 조사하는 것을 추천합니다. 예를 들어, vim용 플러그인이 있습니다.

Lefthook을 통한 사전 푸시 정적 분석

Lefthook은 Git 커밋 또는 푸시 전에 사용자 지정 논리를 실행할 수 있게 해주는 Git 훅 관리 도구입니다.

GitLab은 Lefthook 구성을 제공합니다 (lefthook.yml), 하지만 설치해야 합니다.

우리는 체크인된 lefthook.yml을 가지고 있지만, Lefthook이 설치될 때까지 무시됩니다.

Overcommit 제거하기

우리는 Lefthook 이전에 Overcommit을 사용하고 있었으므로, 먼저 overcommit --uninstall로 제거하는 것이 좋습니다.

Lefthook 설치하기

  1. 다양한 방법으로 lefthook을 설치할 수 있습니다.

    전역적으로 설치하지 않겠다면 (예: Homebrew 또는 패키지 관리자 사용) GitLab 프로젝트에만 사용하고자 할 경우, 다음과 같이 Ruby gem을 설치할 수 있습니다:

    bundle install

  2. Lefthook 관리 Git 훅을 설치합니다:

    # 전역으로 설치된 경우
lefthook install
# Ruby gem을 통해 설치된 경우
bundle exec lefthook install

  3. Lefthook이 작동하는지 확인하려면 Lefthook pre-push Git 훅을 실행합니다:

    # 전역으로 설치된 경우
lefthook run pre-push
# Ruby gem을 통해 설치된 경우
bundle exec lefthook run pre-push

이 명령은 Lefthook 버전과 출력과 함께 실행 가능한 명령 목록을 반환해야 합니다.

Lefthook 구성

Lefthook은 다음 조합으로 구성됩니다:

Lefthook 자동 수정 파일

우리는 모든 린터를 실행하는 커스텀 lefthook 대상을 가지고 있지만, 변경된 파일에 대해서만 자동 수정 기능을 지원합니다.

# 전역으로 설치된 경우
lefthook run auto-fix
# Ruby gem을 통해 설치된 경우
bundle exec lefthook run auto-fix

Lefthook을 일시적으로 비활성화

Lefthook을 일시적으로 비활성화하려면 LEFTHOOK 환경 변수를 0으로 설정할 수 있습니다. 예를 들어:

LEFTHOOK=0 git push ...

Lefthook 훅을 수동으로 실행하기

pre-push Git 훅을 실행하려면 다음과 같이 합니다:

bundle exec lefthook run pre-push

자세한 정보는 Lefthook 문서를 참조하세요.

태그별 Lefthook 체크 건너뛰기

푸시할 때 태그에 따라 일부 체크를 건너뛰려면 LEFTHOOK_EXCLUDE 환경 변수를 설정할 수 있습니다. 예를 들어:

LEFTHOOK_EXCLUDE=frontend,documentation git push ...

대안으로, 다음 구조의 lefthook-local.yml을 생성할 수 있습니다:

pre-push:
  exclude_tags:
    - frontend
    - documentation

자세한 정보는 Lefthook 문서를 참조하세요.

특정 Lefthook 체크 건너뛰거나 활성화하기

푸시할 때 이름에 따라 체크를 건너뛰거나 활성화하려면 해당 훅의 lefthook-local.yml 섹션에 skip: true 또는 skip: false를 추가할 수 있습니다. 예를 들어, locale/gitlab.pot의 문제를 감지하기 위해 gettext 체크를 활성화하고 싶을 수 있습니다:

pre-push:
  commands:
    gettext:
      skip: false

자세한 정보는 Lefthook 문서의 명령 건너뛰기 섹션을 참조하세요.

데이터베이스 마이그레이션

전용 데이터베이스 마이그레이션 스타일 가이드를 참조하세요.

자바스크립트

전용 JS 스타일 가이드를 참조하세요.

SCSS

전용 SCSS 스타일 가이드를 참조하세요.

루비

전용 루비 스타일 가이드를 참조하세요.

고

전용 Go 표준 및 스타일 가이드를 참조하세요.

셸 명령 (루비)

전용 GitLab 코드베이스의 셸 명령 가이드라인을 참조하세요.

셸 스크립팅

전용 셸 스크립팅 표준 및 스타일 가이드를 참조하세요.

마크다운

Ciro Santilli의 마크다운 스타일 가이드를 따릅니다.

문서화

전용 문서화 스타일 가이드를 참조하세요.

모범 사례를 위한 가이드라인

모범 사례 예시는 권장되는 코드 작성 방법을 보여주고 피해야 할 관행의 예와 비교합니다. 이러한 예시는 나쁨 또는 좋음으로 레이블이 붙습니다. GitLab 개발 가이드라인에서는 사례를 제시할 때 먼저 나쁜 것을 보여준 다음 좋은 것을 따라가는 전략을 권장합니다. 먼저 나쁜 관행(어떻게 할 수 있는지를 보여주는 것이며, 종종 여전히 작동하는 코드)을 보여주고, 그런 다음 좋은 예를 사용하여 더 나은 방법을 설명합니다. 이것은 일반적으로 같은 코드의 개선된 예입니다.

예제를 제공할 때 다음 가이드라인을 고려하세요:

  • 먼저 나쁜 예를 제공한 다음 좋은 예를 제공하세요.
  • 하나의 나쁜 경우와 하나의 좋은 경우만 주어질 때는 같은 코드 블록을 사용하세요.
  • 둘 이상의 나쁜 경우 또는 좋은 경우가 제공될 때는 각각 분리된 코드 블록을 사용하세요. 여러 예시가 제시될 때, 명확한 구분이 독자가 좋은 부분으로 직접 이동하는 데 도움이 됩니다. 무언가가 나쁜 관행인 이유에 대한 설명(주석 또는 리소스 링크 등)을 제공하는 것을 고려하세요.
  • 나은 경우와 최고의 경우는 좋은 경우 코드 블록의 일부로 간주될 수 있습니다. 같은 코드 블록에서 각 경우 앞에 # Better 및 # Best라는 주석을 붙입니다.

GitLab 개발 가이드라인에서는 나쁜 것-좋은 것 접근 방식이 허용되지만, 사용자 문서에서는 사용하지 마세요. 사용자 문서에서는 해야 할 것과 하지 말아야 할 것을 사용하세요. 예시를 보려면 Pajamas Design System을 참조하세요.

파이썬

전용 파이썬 개발 가이드라인을 참조하세요.

기타

코드는 미국 영어로 작성되어야 합니다.