• 에디터/IDE 스타일 표준화
• Pre-push 정적 분석 - Lefthook
  • Overcommit 제거
  • Lefthook 설치
  • Lefthook 구성
  • 자동으로 파일 수정하는 Lefthook
  • Lefthook 일시적 비활성화
  • Lefthook 후크 수동 실행
  • 태그별 Lefthook 체크 건너뛰기
  • 특정 Lefthook 체크 건너뛰기 또는 활성화하기
• 데이터베이스 마이그레이션
• JavaScript
• SCSS
• 루비
• Go
• 셸 명령어 (루비)
• 셸 스크립팅
• 마크다운
• 문서
  • 좋은 실천 지침
• 파이썬
• 기타

개발 스타일 가이드

에디터/IDE 스타일 표준화

로컬에서 파일을 저장하기 전에 특정한 스타일링 표준을 자동으로 적용하기 위해 EditorConfig를 사용합니다. 일부 에디터 및 IDE는 .editorconfig 설정을 자동으로 기본값으로 적용합니다.

에디터 또는 IDE가 .editorconfig을 자동으로 지원하지 않는 경우, 플러그인이 존재하는지 확인해보는 것이 좋습니다. 예를 들어, vim용 플러그인이 있습니다.

Pre-push 정적 분석 - 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.yml에 프로젝트 구성
• 로컬 구성

자동으로 파일 수정하는 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 체크 건너뛰기 또는 활성화하기

푸시할 때 해당 후크 섹션에 skip: true 또는 skip: false를 추가하여 해당 이름을 기준으로 체크를 건너뛰거나 활성화할 수 있습니다. 예를 들어, locale/gitlab.pot에서 문제를 감지하기 위해 gettext 체크를 활성화하려면 다음과 같이 할 수 있습니다:

pre-push:
  commands:
    gettext:
      skip: false

자세한 내용은 Lefthook 문서 체크 건너뛰기 섹션을 확인하세요.

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

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

JavaScript

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

SCSS

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

루비

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

Go

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

셸 명령어 (루비)

GitLab 코드베이스에서의 셸 명령어에 대한 가이드라인을 참조하세요.

셸 스크립팅

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

마크다운

Ciro Santilli’s 마크다운 스타일 가이드를 따르고 있습니다.

문서

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

좋은 실천 지침

좋은 실천 예제는 코드 작성의 권장 방법을 보여주며 피하는 것을 권장하는 사례와 비교합니다. 이러한 예제는 나쁜 또는 좋은으로 레이블이 지정됩니다. GitLab 개발 지침에서는 경우를 제시할 때 먼저-나쁜-그 다음-좋은 전략을 따르는 것이 좋습니다. 먼저 나쁜 예제를 보여주고(일반적으로 여전히 작동하는 코드인 경우가 많음), 그런 다음 어떻게 더 나아지는지를 보여주는 좋은 예제를 보여줍니다. 이는 일반적으로 동일한 코드의 개선된 예입니다.

예제를 제공할 때 다음 지침을 고려하세요:

• 먼저 나쁜 예제를 제시한 다음 좋은 예제를 제시하세요.
• 나쁜 경우와 좋은 경우가 각각 하나씩만 제공되는 경우, 동일한 코드 블록을 사용하세요.
• 여러 나쁜 경우나 하나의 좋은 경우가 제시되는 경우, 각각에 대해 별도의 코드 블록을 사용하세요. 많은 예가 제시되는 경우 명확한 분리가 독자가 좋은 부분으로 바로 이동하는 데 도움이 됩니다. 왜 어떤 것이 나쁜 실천인지 설명을 제공하는 것을 고려하세요(예: 주석 또는 리소스에 대한 링크).
• 더 나은 경우와 최상의 경우는 좋은 경우의 코드 블록의 일부로 간주될 수 있습니다. 동일한 코드 블록에서 각각에 대해 다음 주석을 달아야 합니다: # 더 나은 그리고 # 최상의.

나쁜 다음 좋은 접근 방식은 GitLab 개발 가이드라인에서 허용되지만 사용자 설명서에는 사용하지 마십시오. 사용자 설명서에는 실천과 하지 말아야 할 것을 사용하세요. 예제는 Pajamas Design System을 참조하세요.

파이썬

전용 파이썬 개발 지침을 참조하세요.

기타

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