전역 푸시 규칙 활성화
프로젝트별 전역 푸시 규칙 무시
사용자 확인
커밋 메시지 유효성 검사
DCO 인증이 없는 커밋 거부
브랜치 이름 유효성 검사
의도하지 않은 결과 방지
파일 유효성 검사
- 저장소에 비밀 정보 푸시 방지
- 파일 이름으로 차단
관련 주제
문제 해결

푸시 규칙

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated

일반적으로 정규 표현식의 최대 길이인 255에서 511로 변경되었습니다. 변경 사항은 여기에서 확인할 수 있습니다.

푸시 규칙은 사용자 친화적 인터페이스에서 활성화할 수 있는 pre-receive Git 훅입니다. 푸시 규칙을 사용하면 리포지토리로 푸시할 수 있는 내용에 대해 더 많은 제어권을 획들할 수 있습니다. GitLab이 보호된 브랜치를 제공하는 반면, 더 구체적인 규칙이 필요할 수도 있습니다. 예를 들어 다음과 같습니다:

커밋 내용을 평가하는 것.
커밋 메시지가 기대 형식과 일치하는지 확인하는 것.
브랜치 이름 규칙을 강제하는 것.
파일의 세부 정보를 평가하는 것.
Git 태그의 제거를 방지하는 것.

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

사용자 정의 푸시 규칙에는 서버 훅을 사용하십시오.

전역 푸시 규칙 활성화

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

사전 요구 사항:

관리자 여야 합니다.

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

왼쪽 사이드바에서 맨 아래로 이동하여 관리자 영역을 선택합니다.
푸시 규칙을 선택합니다.
푸시 규칙을 확장합니다.
원하는 규칙을 설정합니다.
푸시 규칙 저장을 선택합니다.

프로젝트별 전역 푸시 규칙 무시

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

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

사용자 확인

커밋을 만드는 사용자를 유효성 검사하는 데 이러한 규칙을 사용합니다.

확인되지 않은 사용자 거부: 사용자는 확인된 이메일 주소를 가져야 합니다.
커밋 작성자가 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 인증이 없는 커밋 거부

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}$
```

의도하지 않은 결과 방지

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

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

파일 유효성 검사

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

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

저장소에 비밀 정보 푸시 방지

13.9 버전에서 GitLab Premium으로 이전되었습니다.

인증 파일 및 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 키 (GitLab 14.8 버전 이상):
- /ssh/id_ecdsa_sk
- /.ssh/personal_ecdsa_sk
- /config/server_ecdsa_sk
- id_ecdsa_sk
- .id_ecdsa_sk
개인 ED25519_SK SSH 키 (GitLab 14.8 버전 이상):
- /ssh/id_ed25519_sk
- /.ssh/personal_ed25519_sk
- /config/server_ed25519_sk
- id_ed25519_sk
- .id_ed25519_sk
다음 접미사로 끝나는 모든 파일:
- *.pem
- *.key
- *.history
- *_history

파일 이름으로 차단

13.9 버전에서 GitLab Premium으로 이전되었습니다.

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 13.10부터 서명되지 않은 커밋 거부 푸시 규칙이 있는 프로젝트에서는 사용자가 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를 읽어보세요.

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

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

예를 들어, 레일즈 콘솔을 사용하여 커밋 작성자가 GitLab 사용자인지 확인과 사용자가 git push로 Git 태그를 제거하지 못하도록 함 확인란을 활성화하고, 특정 이메일 도메인에서만 커밋을 허용하는 필터를 생성하는 방법은 다음과 같습니다:

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

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

푸시 규칙

전역 푸시 규칙 활성화

프로젝트별 전역 푸시 규칙 무시

사용자 확인

커밋 메시지 유효성 검사

DCO 인증이 없는 커밋 거부

브랜치 이름 유효성 검사

의도하지 않은 결과 방지

파일 유효성 검사

저장소에 비밀 정보 푸시 방지

파일 이름으로 차단

관련 주제

문제 해결

서명되지 않은 커밋 푸시 규칙이 Web IDE를 비활성화함

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

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

도움말

기능 사용 가능성과 제품 평가판

도움받기