• 편집기/IDE 스타일 표준화
• 푸시 전 정적 분석
  • Overcommit 제거
  • Lefthook 설치
  • Lefthook 구성
  • Lefthook 자동 수정 파일
  • Lefthook 일시적 비활성화
  • Lefthook 후크 수동 실행
  • 태그별 Lefthook 확인 건너뛰기
  • 특정 Lefthook 확인 건너뛰기 또는 활성화
• 데이터베이스 마이그레이션
• JavaScript
• SCSS
• Ruby
• Go
• 셸 명령어 (루비)
• 셸 스크립팅
• Markdown
• 문서
  • 좋은 관행을 위한 지침
• Python
• Misc

개발 스타일 가이드

편집기/IDE 스타일 표준화

로컬로 파일을 저장하기 전에 일부 스타일을 자동으로 적용하기 위해 EditorConfig를 사용합니다. 일부 편집기 및 IDE는 .editorconfig 설정을 기본적으로 자동으로 따릅니다.

만약 사용 중인 편집기나 IDE가 .editorconfig을 자동으로 지원하지 않는다면, 플러그인이 있는지 확인해보시기를 권장합니다. 예를 들어, vim용 플러그인이 있습니다.

푸시 전 정적 분석

Lefthook은 Git 후크 관리자로, 커밋이나 푸시 직전에 사용자 정의 논리를 실행할 수 있습니다. GitLab에는 Lefthook 구성 (lefthook.yml)이 함께 제공되지만 설치해야 합니다.

우리는 lefthook.yml을 확인했지만, Lefthook가 설치되기 전까지는 무시됩니다.

Overcommit 제거

Lefthook 이전에 Overcommit을 사용하고 있었으므로 먼저 overcommit --uninstall로 제거할 수 있습니다.

Lefthook 설치

1. 여러 가지 방법으로 lefthook을 설치할 수 있습니다. 전역으로 설치하지 않을 경우(예: Homebrew 또는 패키지 관리자를 통해), GitLab 프로젝트에서만 사용하려면 루비 젬을 다음과 같이 설치할 수 있습니다:

   bundle install
   

2. Lefthook으로 관리되는 Git 후크를 설치합니다:

   # 전역으로 설치한 경우
   lefthook install
   # 루비 젬을 통해 설치한 경우
   bundle exec lefthook install
   

3. Lefthook의 pre-push Git 후크를 실행하여 작동 여부를 테스트합니다:

   # 전역으로 설치한 경우
   lefthook run pre-push
   # 루비 젬을 통해 설치한 경우
   bundle exec lefthook run pre-push
   

이렇게 하면 Lefthook 버전과 실행 가능한 명령어 목록이 반환될 것입니다.

Lefthook 구성

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

• lefthook.yml에서의 프로젝트 구성
• 로컬 구성

Lefthook 자동 수정 파일

자동 수정 기능을 갖는 모든 린터를 실행하는 사용자 정의 lefthook 대상이 있습니다. 하지만 이는 브랜치에서 변경된 파일에 대해서만 적용됩니다.

# 전역으로 설치한 경우
lefthook run auto-fix
# 루비 젬을 통해 설치한 경우
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 스타일 가이드를 참조하세요.

Ruby

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

Go

전용 Go 표준 및 스타일 지침를 참조하세요.

셸 명령어 (루비)

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

셸 스크립팅

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

Markdown

Ciro Santilli의 Markdown 스타일 가이드를 따르고 있습니다.

문서

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

좋은 관행을 위한 지침

좋은 관행 예시는 코드 작성을 권장하는 방법을 나쁜 예시와 비교하며 보여줍니다. 이들 예시는 나쁨 또는 좋음으로 라벨이 달립니다. GitLab 개발 지침에서는 경우에 따라 나쁜-좋음 전략을 따르는 것이 권장됩니다. 먼저 나쁜 관행을 보여주고(일반적으로 여전히 작동하는 코드), 그런 다음에 어떻게 좋은 예시로 개선할 수 있는지 보여줍니다.

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

• 먼저 나쁜 예시를 제시한 후에 좋은 예시를 제시하세요.
• 나쁜 경우가 하나이고 좋은 경우가 하나인 경우, 동일한 코드 블록을 사용합니다.
• 여러 개의 나쁜 경우나 하나의 좋은 경우가 제공되는 경우, 각각에 대해 별도의 코드 블록을 사용하세요.
• 많은 예시가 제시될 때는 명확한 구분이 도움이 됩니다. 분리하여 제시해 독자가 직접적으로 좋은 부분을 찾을 수 있도록 합니다. 어떤 것이 나쁜 관행인지에 대한 설명(예: 주석 또는 리소스 링크)을 고려하세요.
• 더 나은 예시와 최상의 경우는 좋은 경우의 코드 블록의 일부로 볼 수 있습니다. 동일한 코드 블록에 각각에 대해 # 더 나은과 # 최상을 선행시킵니다.

GitLab 개발 지침에서는 나쁜-좋음 접근 방식이 허용되지만, 사용자 문서에는 사용하지 마세요. 사용자 문서에는 해야 하는 것과 하면 안 되는 것을 사용하세요. 예시는 Pajamas Design System을 참조하세요.

Python

전용 Python 개발 가이드라인을 확인하세요.

Misc

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