- 에디터/IDE 스타일 표준화
- Lefthook을 통한 사전 푸시 정적 분석
- 데이터베이스 마이그레이션
- 자바스크립트
- SCSS
- 루비
- 고
- 셸 명령 (루비)
- 셸 스크립팅
- 마크다운
- 문서화
- 파이썬
- 기타
개발 스타일 가이드
에디터/IDE 스타일 표준화
우리는 EditorConfig를 사용하여 파일이 로컬로 저장되기 전에 특정 스타일 표준을 자동으로 적용합니다.
일부 에디터와 IDE는 기본적으로 .editorconfig
설정을 자동으로 지원합니다.
만약 당신의 에디터나 IDE가 .editorconfig
를 자동으로 지원하지 않는다면, 플러그인이 존재하는지 조사하는 것을 추천합니다. 예를 들어, vim용 플러그인이 있습니다.
Lefthook을 통한 사전 푸시 정적 분석
Lefthook은 Git 커밋 또는 푸시 전에 사용자 지정 논리를 실행할 수 있게 해주는 Git 훅 관리 도구입니다.
GitLab은 Lefthook 구성을 제공합니다 (lefthook.yml
), 하지만 설치해야 합니다.
우리는 체크인된 lefthook.yml
을 가지고 있지만, Lefthook이 설치될 때까지 무시됩니다.
Overcommit 제거하기
우리는 Lefthook 이전에 Overcommit을 사용하고 있었으므로, 먼저 overcommit --uninstall
로 제거하는 것이 좋습니다.
Lefthook 설치하기
-
다양한 방법으로 lefthook을 설치할 수 있습니다.
전역적으로 설치하지 않겠다면 (예: Homebrew 또는 패키지 관리자 사용) GitLab 프로젝트에만 사용하고자 할 경우, 다음과 같이 Ruby gem을 설치할 수 있습니다:
bundle install
-
Lefthook 관리 Git 훅을 설치합니다:
# 전역으로 설치된 경우 lefthook install # Ruby gem을 통해 설치된 경우 bundle exec lefthook install
-
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 체크 건너뛰거나 활성화하기
푸시할 때 이름에 따라 체크를 건너뛰거나 활성화하려면 해당 훅의 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을 참조하세요.
파이썬
전용 파이썬 개발 가이드라인을 참조하세요.
기타
코드는 미국 영어로 작성되어야 합니다.