편집기/IDE 스타일 표준화#

EditorConfig를 사용하여 파일이 로컬에 저장되기 전 특정 스타일 표준을 자동으로 적용합니다. 일부 편집기 및 IDE는 기본적으로 자동으로 .editorconfig 설정을 적용합니다.

편집기나 IDE가 .editorconfig를 자동으로 지원하지 않는 경우, 플러그인이 있는지 확인해 보세요. 예를 들어, vim용 플러그인이 있습니다.

Lefthook을 사용한 커밋 전/푸시 전 정적 분석#

Lefthook은 Git 커밋 또는 푸시 전에 커스텀 로직을 실행할 수 있도록 해주는 Git hooks 관리자입니다. GitLab은 Lefthook 설정(lefthook.yml)이 포함되어 있지만, 반드시 설치해야 합니다.

lefthook.yml이 체크인되어 있지만 Lefthook이 설치되기 전까지는 무시됩니다.

Overcommit 제거#

이전에는 Lefthook 대신 Overcommit을 사용했으므로, overcommit --uninstall 명령으로 먼저 제거하는 것이 좋습니다.

Lefthook 설치#

Lefthook은 다양한 방법으로 설치할 수 있습니다. 전역(예: Homebrew 또는 패키지 관리자를 통해)으로 설치하지 않고 GitLab 프로젝트에만 사용하고 싶다면, Ruby gem으로 설치할 수 있습니다:

bundle install

Lefthook 관리 Git hooks 설치:

# If installed globally
lefthook install
# Or if installed via ruby gem
bundle exec lefthook install

Lefthook pre-push Git hook을 실행하여 Lefthook이 동작하는지 테스트합니다:

# If installed globally
lefthook run pre-push
# Or if installed via ruby gem
bundle exec lefthook run pre-push

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

Lefthook 설정#

Lefthook은 다음의 조합으로 설정됩니다:

• lefthook.yml의 프로젝트 설정.

• 모든 로컬 설정.

Lefthook 파일 자동 수정#

브랜치에서 변경된 파일에 대해서만 자동 수정 기능이 있는 모든 린터를 실행하는 커스텀 lefthook 타깃이 있습니다.

# If installed globally
lefthook run auto-fix
# Or if installed via ruby gem
bundle exec lefthook run auto-fix

Lefthook 일시적으로 비활성화#

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

LEFTHOOK=0 git push ...

Lefthook hooks 수동 실행#

pre-commit, pre-push, auto-fix hooks를 수동으로 실행할 수 있습니다. 예:

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 검사 건너뛰기 또는 활성화#

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

pre-push:
  commands:
    gettext:
      skip: false

자세한 내용은 Lefthook 문서 명령 건너뛰기 섹션을 참조하세요.

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

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

JavaScript#

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

SCSS#

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

Ruby#

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

Go#

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

Shell 명령 (Ruby)#

전용 GitLab 코드베이스에서 shell 명령에 대한 가이드라인을 참조하세요.

Shell 스크립팅#

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

npmjs.com에 NPM 패키지 게시#

전용 npmjs 패키지 게시 가이드를 참조하세요.

Markdown#

Ciro Santilli의 Markdown 스타일 가이드를 따릅니다.

문서#

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

좋은 예시를 위한 가이드라인#

좋은 예시는 권장되는 코드 작성 방식을 보여주면서, 피해야 할 예시와 비교합니다. 이러한 예시는 "Bad" 또는 "Good"으로 레이블링됩니다. GitLab 개발 가이드라인에서 사례를 제시할 때는 "먼저 나쁜 것, 그 다음 좋은 것(first-bad-then-good)" 전략을 따르는 것이 권장됩니다. 먼저 "Bad" 예시(종종 여전히 동작하는 코드인, 어떻게 할 수도 있는지)를 보여주고, 그 다음 "Good" 예시를 사용하여 어떻게 더 잘 해야 하는지를 보여줍니다. 이는 일반적으로 동일한 코드의 개선된 예시입니다.

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

• 먼저 "Bad" 예시를 제공하고, 그 다음 "Good" 예시를 제공합니다.

• 나쁜 사례 하나와 좋은 사례 하나만 있는 경우, 동일한 코드 블록을 사용합니다.

• 나쁜 사례 또는 좋은 사례가 둘 이상 있는 경우, 각각 별도의 코드 블록을 사용합니다. 많은 예시가 제시될 때, 명확한 구분이 독자가 좋은 부분으로 바로 이동하는 데 도움이 됩니다. 왜 나쁜 예시인지에 대한 설명(예: 주석 또는 리소스 링크)을 제공하는 것을 고려하세요.

• 더 나은 사례와 최선의 사례는 좋은 사례 코드 블록의 일부로 간주할 수 있습니다. 동일한 코드 블록에서 각각 주석으로 앞에 붙입니다: # Better 및 # Best.

나쁜 것 다음 좋은 것 접근 방식은 GitLab 개발 가이드라인에서 허용되지만, 사용자 문서에는 사용하지 마세요. 사용자 문서에는 Do와 Don't를 사용하세요. 예시는 Pajamas 디자인 시스템을 참조하세요.

Python#

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

기타#

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