푸시 규칙

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, 셀프매니지드, GitLab Dedicated

푸시 규칙은 사용하기 쉬운 인터페이스에서 활성화할 수 있는 pre-receive Git 훅입니다. 푸시 규칙을 사용하면 리포지토리로 푸시할 수 있는 내용을 더욱 정밀하게 제어할 수 있습니다. GitLab은 보호된 브랜치를 제공하지만, 더 구체적인 규칙이 필요할 수 있습니다. 예를 들어 다음과 같습니다:

  • 커밋 내용 평가
  • 커밋 메시지가 예상 형식과 일치하는지 확인
  • 브랜치 이름 규칙 수행
  • 파일 세부 정보 평가
  • Git 태그 제거 방지

GitLab은 푸시 규칙의 정규 표현식으로 RE2 구문을 사용합니다. 이를 regex101 regex tester에서 테스트할 수 있습니다. 각 정규 표현식의 길이는 511자로 제한됩니다.

사용자 정의 푸시 규칙을 위해서는 서버 후크를 사용하세요.

전역 푸시 규칙 활성화

새 프로젝트에 상속될 푸시 규칙을 생성할 수 있지만, 프로젝트나 그룹에서 재정의할 수도 있습니다. 전역 푸시 규칙을 구성한 후에 생성된 모든 프로젝트에는 이 구성이 상속됩니다. 그러나 각 기존 프로젝트는 프로젝트별 전역 푸시 규칙 재정의에 설명된 프로세스를 사용하여 수동으로 업데이트해야 합니다.

필수 조건:

  • 관리자여야 합니다.

전역 푸시 규칙을 생성하려면:

  1. 좌측 사이드바에서 아래쪽에서 관리자를 선택합니다.
  2. 푸시 규칙을 선택합니다.
  3. 푸시 규칙을 확장합니다.
  4. 원하는 규칙을 설정합니다.
  5. 푸시 규칙 저장을 선택합니다.

프로젝트별 전역 푸시 규칙 재정의

개별 프로젝트의 푸시 규칙은 전역 푸시 규칙을 재정의합니다. 특정 프로젝트에 대해 전역 푸시 규칙을 재정의하거나 기존 프로젝트의 규칙을 새로운 전역 푸시 규칙과 일치하도록 업데이트하려면:

  1. 좌측 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 설정 > 저장소를 선택합니다.
  3. 푸시 규칙을 확장합니다.
  4. 원하는 규칙을 설정합니다.
  5. 푸시 규칙 저장을 선택합니다.

사용자 확인

커밋을 만드는 사용자를 확인하기 위해 이러한 규칙을 사용하세요.

참고: 이러한 푸시 규칙은 커밋에만 적용되며 태그에는 적용되지 않습니다.

  • 확인되지 않은 사용자 거부: 사용자는 확인된 이메일 주소를 가져야 합니다.
  • 커밋 작성자가 GitLab 사용자인지 확인: 커밋 작성자와 커미터는 GitLab에 의해 확인된 이메일 주소를 가져야 합니다.
  • 커밋 작성자 이메일: 작성자와 커미터 이메일 주소가 정규 표현식과 일치해야 합니다. 아무 이메일 주소를 허용하려면 비워 두세요.

커밋 메시지 유효성 검사

커밋 메시지를 위한 이러한 규칙을 사용하세요.

  • 커밋 메시지에 표현식 필요: 메시지는 표현식과 일치해야 합니다. 아무 커밋 메시지를 허용하려면 비워 두세요. 여러 줄 모드를 사용하여, (?-m)을 사용해 비활성화할 수 있습니다. 일부 유효성 검사 예제:

    • JIRA\-\d+Refactored css. Fixes JIRA-123와 같이 모든 커밋이 Jira 이슈를 참조하도록 요구합니다.
    • [[:^punct:]]\b$는 커밋이 마지막 문자가 구두점인 경우 해당 커밋을 거부합니다. 단어 경계 문자(\b)는 Git이 커밋 메시지 끝에 새 줄 문자(\n)를 추가하기 때문에 잘못된 부정을 방지합니다.

    GitLab UI에서 생성된 커밋 메시지는 새 줄 문자로 \r\n을 설정합니다. 올바르게 일치시키기 위해 정규 표현식에서 \n 대신에 (\r\n?|\n)을 사용하세요.

    예를 들어, 다음과 같은 다중 라인 커밋 설명이 있다면:

    JIRA:
    Description
    

    정규 표현식으로 다음을 검증할 수 있습니다: JIRA:(\r\n?|\n)\w+.

  • 커밋 메시지에서 표현식 거부: 메시지는 표현식과 일치해서는 안 됩니다. 아무 커밋 메시지를 허용하려면 비워 두세요. 여러 줄 모드를 사용하여, (?-m)을 사용해 비활성화할 수 있습니다.

서명되지 않은 커밋 거부

  • GitLab 15.5에서 도입되었습니다.

Developer Certificate of Origin (DCO)로 서명된 커밋은 기여자가 해당 커밋에서 기여한 코드를 작성하거나 제출할 권한이 있다는 것을 인증합니다. 프로젝트의 모든 커밋이 DCO를 준수하도록 요구할 수 있습니다. 이 푸시 규칙은 모든 커밋 메시지에 Signed-off-by: 트레일러를 필요로 하며, 해당 트레일러가 없는 커밋은 거부됩니다.

브랜치 이름 유효성 확인

브랜치 이름을 유효성 검사하려면 브랜치 이름에 대한 정규 표현식을 입력하세요. 아무 브랜치 이름을 허용하려면 비워 두세요. 당신의 기본 브랜치는 항상 허용됩니다. 브랜치 이름에 대한 특정 형식은 보안 목적을 위해 기본적으로 제한됩니다. Git 커밋 해시와 유사한 40개의 16진수 문자로 이루어진 이름은 금지됩니다.

일부 유효성 검사 예제:

  • 브랜치는 JIRA-로 시작해야 합니다.

    ^JIRA-
    
  • 브랜치는 -JIRA$로 끝나야 합니다.

    -JIRA$
    
  • 브랜치는 길이가 4에서 15 사이이며, 소문자, 숫자, 대시만 허용합니다.

    ^[a-z0-9\\-]{4,15}$
    

의도하지 않은 결과 방지

의도하지 않은 결과를 방지하기 위해 이러한 규칙을 사용하세요.

  • 서명되지 않은 커밋 거부: 커밋이 서명되어야 합니다. 이 규칙은 웹 IDE에서 생성된 몇몇 정당한 커밋을 차단하고 있을 수 있으며, GitLab UI에서 생성한 서명되지 않은 커밋을 허용할 수 있습니다.
  • 사용자가 git push를 사용하여 Git 태그를 제거하지 못하게 함: 사용자는 git push를 사용해서 Git 태그를 제거할 수 없습니다. 사용자는 UI에서 태그를 삭제할 수 있습니다.

파일 유효성 검사

커밋에 포함된 파일을 유효성 검사하는 데 이러한 규칙을 사용합니다.

  • 비밀 파일 푸시 방지: 파일에는 비밀 정보가 포함되어서는 안 됩니다.
  • 금지된 파일 이름: 리포지토리에 존재하지 않는 파일 이름은 정규 표현식과 일치해서는 안 됩니다. 모든 파일 이름을 허용하려면 비워 두세요. 일반적인 예제를 참조하세요.
  • 최대 파일 크기: 추가되거나 업데이트된 파일의 크기는 이 파일 크기(단위: MB)를 초과해서는 안 됩니다. 모든 크기의 파일을 허용하려면 0으로 설정하세요. Git LFS가 추적하는 파일은 면제됩니다.

리포지토리로의 비밀 정보 푸시 방지

인증 파일 및 SSH 개인 키와 같은 비밀 정보를 버전 관리 시스템에 커밋해서는 안 됩니다. GitLab에서는 파일 목록을 사용하여 리포지토리에서 해당 파일들을 차단할 수 있습니다. 목록과 일치하는 파일이 있는 병합 요청은 차단됩니다. 이 푸시 규칙은 이미 리포지토리에 커밋된 파일에는 제한을 두지 않습니다. 기존 프로젝트의 구성을 업데이트하여 이 규칙을 사용하려면 프로젝트별 전역 푸시 규칙 재정의에 설명된 프로세스를 사용해야 합니다.

이 규칙에 의해 차단된 파일은 아래에 나열되어 있습니다. 자세한 기준 목록은 files_denylist.yml을 참조하세요.

  • AWS CLI 자격 증명 블롭:

    • .aws/credentials
    • aws/credentials
    • homefolder/aws/credentials
  • 개인 RSA SSH 키:

    • /ssh/id_rsa
    • /.ssh/personal_rsa
    • /config/server_rsa
    • id_rsa
    • .id_rsa
  • 개인 DSA SSH 키:

    • /ssh/id_dsa
    • /.ssh/personal_dsa
    • /config/server_dsa
    • id_dsa
    • .id_dsa
  • 개인 ED25519 SSH 키:

    • /ssh/id_ed25519
    • /.ssh/personal_ed25519
    • /config/server_ed25519
    • id_ed25519
    • .id_ed25519
  • 개인 ECDSA SSH 키:

    • /ssh/id_ecdsa
    • /.ssh/personal_ecdsa
    • /config/server_ecdsa
    • id_ecdsa
    • .id_ecdsa
  • 개인 ECDSA_SK SSH 키:

    • /ssh/id_ecdsa_sk
    • /.ssh/personal_ecdsa_sk
    • /config/server_ecdsa_sk
    • id_ecdsa_sk
    • .id_ecdsa_sk
  • 개인 ED25519_SK SSH 키:

    • /ssh/id_ed25519_sk
    • /.ssh/personal_ed25519_sk
    • /config/server_ed25519_sk
    • id_ed25519_sk
    • .id_ed25519_sk
  • 아래 접미사로 끝나는 모든 파일:

    • *.pem
    • *.key
    • *.history
    • *_history

파일 이름으로 금지

Git에서 파일 이름에는 파일의 이름과 이름 앞의 모든 디렉터리가 포함됩니다. git push할 때 각 파일 이름은 금지된 파일 이름에 대한 정규 표현식과 비교됩니다.

금지된 파일 이름 푸시 규칙에는 여러 독립적인 일치를 포함할 수 있도록 정규 표현식을 사용할 수 있습니다. 파일 이름을 넓게 매치하거나 특정 위치에서만 제한할 수 있습니다. 파일 이름 일치는 일부분이거나 확장자에 따라 특정 파일 유형을 제외할 수도 있습니다.

다음 예제들은 정규 표현식 문자 경계 문자를 사용하여 문자열의 시작(^) 및 끝($)에 매치합니다. 또한 디렉터리 경로 또는 파일 이름 양쪽 중 한 곳에 . 또는 /가 들어가거나 두 가지 특수 정규 표현식 문자를 일반 문자로 사용하려면 역슬래시(\)로 이스케이프해야 합니다.

  • .exe 파일을 리포지토리의 모든 위치로 푸시 방지 - 이 정규 표현식은 끝에 .exe가 포함된 모든 파일 이름과 매치합니다:

    \.exe$
    
  • 리포지토리 루트에 특정 구성 파일 푸시 방지

    ^config\.yml$
    
  • 알려진 디렉터리에 특정 구성 파일 푸시 방지

    ^directory-name\/config\.yml$
    
  • 리포지토리의 모든 위치로 특정 파일 푸시 방지 - 이 예제는 install.exe라는 모든 파일에 대해 테스트합니다. 괄호로 묶인 표현 (^|\/)은 디렉터리 구분자를 따르는 파일이나 리포지토리의 루트 디렉터리에 있는 파일 중 하나와 일치합니다:

    (^|\/)install\.exe$
    
  • 이전 표현식을 모두 하나의 표현식으로 결합 - 앞선 표현식은 문자열 끝 글자($)를 의존합니다. 그 부분을 모든 매치 조건의 묶인 모음 끝으로 이동하여 모든 매치에 추가합니다:

    (\.exe|^config\.yml|^directory-name\/config\.yml|(^|\/)install\.exe)$
    

관련 주제

문제 해결

서명되지 않은 커밋을 거부하는 푸시 규칙이 Web IDE를 사용하지 못하게 만듭니다

프로젝트에 서명되지 않은 커밋 거부 푸시 규칙이 있는 경우 사용자는 GitLab Web IDE를 통해 커밋을 만들 수 없습니다.

이 푸시 규칙이 있는 프로젝트에서 Web IDE를 통해 커밋을 허용하려면 GitLab 관리자는 reject_unsigned_commits_by_gitlab 기능 플래그를 비활성화해야 합니다. 기능 플래그를 사용하여 다음 명령으로 비활성화할 수 있습니다.

Feature.disable(:reject_unsigned_commits_by_gitlab)

GitLab UI에서 생성된 서명되지 않은 커밋

서명되지 않은 커밋 거부 푸시 규칙은 GitLab에서 인증되고 생성된 커밋(또는 UI 또는 API를 통해)을 무시합니다. 이 푸시 규칙이 활성화된 경우, 서명되지 않은 커밋이 GitLab 자체에서 만들어진 경우 커밋 히스토리에 여전히 나타날 수 있습니다. 예상대로, GitLab 외부에서 생성되고 리포지토리로 푸시된 커밋은 거부됩니다. 이 문제에 대한 자세한 내용은 이슈 #19185를 참조하세요.

모든 프로젝트에 대한 대량 업데이트 푸시 규칙

모든 프로젝트의 푸시 규칙을 동일하게 업데이트하려면 Rails 콘솔을 사용하거나 각 프로젝트를 업데이트하는 스크립트를 작성하여 푸시 규칙 API 엔드포인트를 사용하세요.

예를 들어, GitLab 사용자인지 확인하고 git push로 Git 태그를 제거하지 못하도록 하는 확인란을 활성화하고 특정 이메일 도메인으로부터의 커밋을 허용하는 필터를 생성해야 할 때, Rails 콘솔을 사용하세요:

경고: 데이터를 변경시키는 명령은 올바르게 실행되지 않거나 적절하지 않은 조건에서 실행될 경우 손상을 일으킬 수 있습니다. 항상 명령을 먼저 테스트 환경에서 실행하고 복원할 백업 인스턴스를 준비하세요.

Project.find_each do |p|
  pr = p.push_rule || PushRule.new(project: p)
  # Check whether the commit author is a GitLab user
  pr.member_check = true
  # Do not allow users to remove Git tags with `git push`
  pr.deny_delete_tag = true
  # Commit author's email
  pr.author_email_regex = '@domain\.com$'
  pr.save!
end