푸시 규칙

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • 정규 표현식 최대 길이를 255에서 511로 변경함 변경 GitLab 16.3에서.

푸시 규칙은 사용자 친화적 인터페이스에서 활성화할 수 있는 pre-receive Git hooks입니다. 푸시 규칙을 사용하면 리포지터리로 푸시할 수 있는 것과 할 수 없는 것에 대한 더 많은 제어권을 얻을 수 있습니다. GitLab은 보호된 브랜치를 제공하지만, 커밋 내용을 평가하거나 커밋 메시지가 예상 형식과 일치하는지 확인하는 등 보다 구체적인 규칙이 필요할 수 있습니다.

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

GitLab은 푸시 규칙에서 정규 표현식에 RE2 syntax를 사용합니다. 이를 regex101 정규식 테스터에서 테스트할 수 있습니다. 각 정규 표현식은 511자로 제한됩니다.

사용자 정의 푸시 규칙에 대해서는 서버 훅을 사용하세요.

전역 푸시 규칙 활성화

새 프로젝트 모두에 대해 푸시 규칙을 만들 수 있지만 프로젝트 수준이나 그룹 수준에서 재정의할 수 있습니다. 전역 푸시 규칙을 구성한 후에 생성되는 모든 프로젝트는 이 구성을 상속받습니다. 하지만 각 기존 프로젝트는 프로젝트별로 전역 푸시 규칙 재정의를 통해 매뉴얼으로 업데이트해야 합니다.

전제 조건:

  • 관리자여야 합니다.

전역 푸시 규칙을 만들려면:

  1. 왼쪽 사이드바의 맨 아래에서 관리자 영역을 선택합니다.
  2. 푸시 규칙을 선택합니다.
  3. 푸시 규칙 확장을 클릭합니다.
  4. 원하는 규칙을 설정합니다.
  5. 푸시 규칙 저장을 선택합니다.

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

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

  1. 왼쪽 사이드바에서 검색 또는 이동하여 찾기 하여 프로젝트를 찾습니다.
  2. 설정 > 리포지터리를 선택합니다.
  3. 푸시 규칙 확장을 클릭합니다.
  4. 원하는 규칙을 설정합니다.
  5. 푸시 규칙 저장을 선택합니다.

사용자 확인

커밋을 하는 사용자를 검증하기 위해 다음 규칙들을 사용하세요.

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

커밋 메시지 유효성 검사

커밋 메시지에 대한 다음 규칙을 사용하세요.

  • 커밋 메시지에서 표현식 필요: 메시지는 표현식에 일치해야 합니다. 모든 커밋 메시지를 허용하려면 비워둘 수 있습니다. 다음은 몇 가지 유효성 검사 예입니다:

    • 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+.

  • 커밋 메시지에서 표현식 거부: 메시지는 표현식과 일치해서는 안 됩니다. 모든 커밋 메시지를 허용하려면 비워둘 수 있습니다.

DCO 인증되지 않은 커밋 거부

Developer Certificate of Origin (DCO)로 서명된 커밋은 해당 커밋에 기여한 사람이 그 코드를 작성하거나 제출할 권리가 있다는 것을 보증합니다. 프로젝트 내 모든 커밋이 DCO를 준수해야 한다면 이 푸시 규칙을 사용할 수 있습니다. 이 규칙은 모든 커밋 메시지에 Signed-off-by: 트레일러를 필요로 하며, 이를 포함하지 않은 모든 커밋을 거부합니다.

브랜치 이름 유효성 검사

브랜치 이름을 유효성 검사하려면 브랜치 이름에 대한 정규 표현식을 입력하세요. 모든 브랜치 이름을 허용하려면 비워둘 수 있습니다. 기본 브랜치는 항상 허용됩니다. 보안상의 이유로 일부 형식의 브랜치 이름이 기본적으로 제한됩니다. Git 커밋 해시와 유사한 40자의 16진수 문자로 된 이름은 금지됩니다.

일부 유효성 검사 예시:

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

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

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

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

의도치 않은 결과 방지

의도치 않은 결과를 방지하기 위해 다음 규칙들을 사용하세요.

파일 유효성 검사

커밋에 포함된 파일을 유효성 검사하려면 다음 규칙을 사용하세요.

  • 비밀 파일 푸시 방지: 파일은 비밀 정보를 포함해서는 안 됩니다.
  • 금지된 파일 이름: 리포지터리에 존재하지 않는 파일은 정규 표현식과 일치해서는 안 됩니다. 모든 파일 이름을 허용하려면 비워둘 수 있습니다. 일반적인 예시 참조.
  • 최대 파일 크기: 추가되거나 업데이트된 파일은 이 파일 크기(MB)를 초과해서는 안 됩니다. 크기가 없는 파일들은 Git LFS에 의해 예외 처리됩니다.

리포지터리에 비밀 정보 푸시 방지

인증 정보 파일이나 SSH 개인 키와 같은 비밀 정보를 버전 관리 시스템에 커밋해서는 안 됩니다. GitLab에서는 이러한 파일을 리포지터리에서 차단하는데 사용자 정의 파일 디렉터리을 사용할 수 있습니다. 디렉터리과 일치하는 파일이 들어 있는 Merge Request는 차단됩니다. 이 푸시 규칙은 이미 리포지터리에 커밋된 파일에는 적용되지 않습니다. 기존 프로젝트의 설정을 업데이트하여 이 규칙을 사용하도록 해야 합니다. 프로젝트별로 전역 푸시 규칙 재정의를 설명하는 프로세스를 사용하여 기존 프로젝트의 구성을 업데이트해야 합니다.

이 규칙에 의해 차단되는 파일은 아래에 나열됩니다. 모든 기준에 대한 완전한 디렉터리은 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할 때, 푸시된 각 파일 이름은 정규 표현식인 금지된 파일 이름과 비교됩니다.

금지된 파일 이름 푸시 규칙에 있는 정규 표현식은 제외할 독립적인 일치 항목을 포함할 수 있습니다. 파일 이름 일치 항목은 리포지터리의 모든 위치에 넓게 또는 특정 위치에만 제한할 수 있습니다. 파일 이름 일치 항목은 또한 부분적이며, 확장자에 따라 파일 유형을 제외할 수 있습니다.

이 예제는 정규 표현식 (regular expressions) 문자 경계 문자를 사용하여 문자열의 시작 부분(^)과 끝($)을 일치시킵니다. 또한 디렉터리 경로나 파일 이름에 . 또는 /가 포함될 수 있는 경우에 대한 사례도 포함됩니다. 이러한 특수한 정규 표현식 문자는 일치 조건으로 사용하려면 백슬래시 \\로 이스케이프해야 합니다.

  • 리포지터리의 모든 위치에 .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를 참조하세요.

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

모든 프로젝트에 대해 푸시 규칙을 동일하게 업데이트하려면, 레일스 콘솔을 사용하거나 푸시 규칙 API 엔드포인트를 사용하여 각 프로젝트를 업데이트하는 스크립트를 작성해야 합니다.

예를 들어, 레일스 콘솔을 사용하여 특정 이메일 도메인에서의 커밋을 허용하는 필터를 만들고, 커밋 저자가 GitLab 사용자인지 확인git push로 Git 태그를 제거할 수 없게 함 체크박스를 활성화하는 경우:

caution
데이터를 변경하는 명령은 올바르게 실행되지 않거나 적절한 조건 하에서 실행되지 않으면 손상을 일으킬 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복원할 준비가 된 백업 인스턴스를 갖추세요.
Project.find_each do |p|
  pr = p.push_rule || PushRule.new(project: p)
  # 커밋 저자가 GitLab 사용자인지 확인
  pr.member_check = true
  # `git push`로 Git 태그를 제거할 수 없게 함
  pr.deny_delete_tag = true
  # 커밋 저자의 이메일
  pr.author_email_regex = '@domain\.com$'
  pr.save!
end