규칙 세트에 사용 가능한 규칙

분기 또는 태그 규칙 집합을 만들어 사용자가 리포지토리에서 선택한 분기 및 태그와 상호 작용하는 방법을 제어합니다. 프라이빗 또는 내부 리포지토리와 리포지토리의 전체 포크 네트워크에 대한 푸시를 차단하는 푸시 규칙 집합을 만들 수도 있습니다.

규칙 세트를 만들 때 특정 사용자가 규칙 세트의 규칙을 무시하도록 허용할 수 있습니다. 특정 역할, 특정 팀 또는 GitHub Apps을(를) 가진 사용자일 수 있습니다.

푸시 규칙 집합의 경우 바이패스 권한은 리포지토리와 리포지토리의 전체 포크 네트워크에 적용됩니다. 이는 이 리포지토리의 전체 포크 네트워크에 있는 모든 리포지토리에 대해 이 규칙 집합을 바이패스할 수 있는 유일한 사용자는 루트 리포지토리에서 이 규칙 집합을 바이패스할 수 있는 사용자뿐임을 의미합니다.

규칙 집합과 바이패스 권한을 만드는 방법에 대한 자세한 내용은 "리포지토리에 대한 규칙 세트 만들기"을(를) 참조하세요.

만들기 제한

선택하면 바이패스 권한이 있는 사용자만 지정한 패턴과 이름이 일치하는 분기 또는 태그를 만들 수 있습니다.

업데이트 제한

선택하면 바이패스 권한이 있는 사용자만 지정한 패턴과 이름이 일치하는 분기 또는 태그로 푸시할 수 있습니다.

삭제 제한

선택하면 바이패스 권한이 있는 사용자만 지정한 패턴과 이름이 일치하는 분기 또는 태그를 삭제할 수 있습니다. 이 규칙은 기본적으로 선택되어 있습니다.

선형 기록 필요

선형 커밋 기록을 적용하면 협력자가 병합 커밋을 대상 분기 또는 태그에 푸시할 수 없습니다. 즉, 분기 또는 태그에 병합된 끌어오기 요청은 Squash 병합 또는 다시 지정 병합을 사용해야 합니다. 엄격한 선형 커밋 기록을 사용하면 팀이 변경 내용을 보다 쉽게 되돌릴 수 있습니다. 메서드에 대한 자세한 내용은 "끌어오기 요청 병합 정보"을(를) 참조하세요.

선형 커밋 기록을 요구하려면 먼저 리포지토리에서 Squash 병합 또는 다시 지정 병합을 허용해야 합니다. 자세한 내용은 "끌어오기 요청 병합 구성"을(를) 참조하세요.

병합 큐 필요

리포지토리 수준에서 병합 큐를 사용하여 병합을 수행해야 할 수 있습니다. 병합 큐에 대한 자세한 내용은 "병합 큐와 끌어오기 요청 병합"을 참조하십시오.

추가 설정

병합 큐 규칙에 대한 다양한 설정을 구성할 수 있습니다.

• 통합 메서드: 당겨받기 요청에서 변경 내용을 병합할 때 사용할 메서드입니다.
• 빌드 동시성: 검사 및 워크플로 실행을 동시에 요청하는 대기 중인 당겨받기 요청 수를 제한합니다.
  • 이 설정은 병합 큐가 merge_group.checks_requested 웹후크 이벤트를 디스패치 하는 시기를 제어합니다. 그러면 merge_group에서 실행되도록 구성된 GitHub Actions 워크플로가 트리거됩니다. 자세한 내용은 "웹후크 이벤트 및 페이로드"을(를) 참조하세요.
  • 예를 들어 큐에 5개의 당겨받기 요청이 추가되고 빌드 동시성 설정이 3인 경우 병합 큐는 처음 3개의 당겨받기 다시 큐에 대한 checks_requested 이벤트를 디스패치 합니다. 이러한 당겨받기 요청 중 하나에 대한 결과를 받으면 병합 큐는 4번째 당겨받기 요청에 대한 이벤트를 디스패치합니다.
• 최소/최대 그룹 크기: 그룹에서 함께 병합될 당겨받기 요청 수입니다.
• 최소 그룹 크기(분)를 충족하기 위한 대기 시간: 첫 번째 당겨받기 요청이 큐에 추가된 후 병합 큐가 대기하여 최소 그룹 크기를 충족하는 시간입니다. 이 시간이 경과하면 최소 그룹 크기가 무시되고 더 작은 그룹이 병합됩니다.
• 필요한 검사를 통과하려면 모든 큐 항목이 필요합니다.
  • 이 설정을 사용하도록 설정하면 병합 그룹의 각 항목이 필요한 모든 검사를 통과해야 합니다.
  • 이 설정을 사용하지 않도록 설정하면 병합 그룹의 헤드에 있는 커밋(예: 그룹의 모든 당겨받기 요청의 변경 내용이 포함된 커밋)만 병합에 필요한 검사를 통과하면 됩니다.
• 상태 검사 시간 제한(분): 상태 확인 필요 결론을 보고하는 최대 시간입니다. 이 많은 시간이 경과한 후에는 결론을 보고하지 않은 검사는 실패한 것으로 간주됩니다.

병합 전 배포 성공 필요

분기를 병합하기 전에 변경 내용을 특정 환경에 성공적으로 배포하도록 요구할 수 있습니다. 예를 들어 이 규칙을 사용하여 변경 내용을 기본 분기에 병합하기 전에 변경 내용이 스테이징 환경에 성공적으로 배포되도록 할 수 있습니다.

서명된 커밋 필요

분기에서 필수 커밋 서명을 사용하도록 설정하면 기여자 은 서명되고 확인된 커밋만 분기에 푸시할 수 있습니다. 자세한 내용은 "커밋 서명 확인 정보"을(를) 참조하세요.

분기 보호 규칙 및 규칙 집합은 분기를 만들 때 다르게 동작합니다. 규칙 집합을 사용하면 다른 분기에서 액세스할 수 없는 커밋만 검사 반면 분기 보호 규칙을 사용하면 일치하는 분기를 만드는 푸시를 제한하지 않는 한 서명된 커밋을 확인하지 않습니다. 둘 다 분기를 업데이트할 때 다른 분기에서 커밋에 연결할 수 있더라도 지정된 범위의 모든 커밋을 검사합니다.

두 방법 모두 verified_signature?를 사용하여 커밋에 유효한 서명이 있는지 확인합니다. 그렇지 않은 경우 업데이트가 수락되지 않습니다.

커밋이 서명되고 확인된 경우 항상 로컬 커밋을 분기에 푸시할 수 있습니다. 그러나 끌어오기 요청을 GitHub Enterprise Server의 분기에 병합할 수는 없습니다. 끌어오기 요청을 로컬로 병합할 수 있습니다. 자세한 내용은 "로컬에서 끌어오기 요청 체크 아웃"을(를) 참조하세요.

병합 전 끌어오기 요청 필요

대상 분기에 대한 모든 변경 내용을 끌어오기 요청과 연결하도록 요청할 수 있습니다. 끌어오기 요청을 반드시 승인할 필요는 없지만 끌어오기 요청을 열어야 합니다.

추가 설정

리포지토리 관리자 또는 "리포지토리 규칙 편집" 권한이 있는 사용자 지정 역할은 누군가가 끌어오기 요청을 보호된 분기에 병합하기 전에 모든 끌어오기 요청이 특정 수의 승인 검토를 받도록 요구할 수 있습니다. 리포지토리에서 쓰기 권한이 있는 사람 또는 지정된 코드 소유자의 승인 검토를 요청할 수 있습니다.

필요한 검토를 사용하도록 설정하면 협력자는 쓰기 권한이 있는 검토자가 필요한 인원수만큼 승인한 끌어오기 요청을 통해서만 분기에 대한 변경 내용을 푸시할 수 있습니다.

사용자가 검토에서 변경 요청 옵션을 선택하는 경우 끌어오기 요청을 먼저 승인해야 병합할 수 있습니다. 끌어오기 요청의 변경을 요청하는 검토자를 사용할 수 없는 경우 리포지토리에 대한 쓰기 권한이 있는 모든 사용자가 차단하는 검토를 해제할 수 있습니다.

모든 필수 검토자가 끌어오기 요청을 승인한 후에도 보류 중이거나 거부된 검토가 있는 동일한 커밋을 가리키는 헤드 분기가 있는 다른 열린 끌어오기 요청이 있는 경우 협력자는 끌어오기 요청을 병합할 수 없습니다. 쓰기 권한이 있는 사용자는 먼저 다른 끌어오기 요청에 대한 차단 검토를 승인하거나 해제해야 합니다.

필요에 따라 풀 요청의 Diff에 영향을 미치는 커밋이 푸시될 때 부실 풀 요청 승인을 해제하도록 선택할 수 있습니다. GitHub은(는) 끌어오기 요청이 승인된 시점에 Diff의 상태를 기록합니다. 이 상태는 검토자가 승인한 일련의 변경 내용을 나타냅니다. Diff가 이 상태에서 변경되는 경우(예: 기여자가 끌어오기 요청 분기에 새 변경 내용을 푸시하거나 업데이트 분기를 클릭하거나 관련 끌어오기 요청이 대상 분기에 병합되기 때문에) 승인 검토가 부실로 해제되고 다른 사용자가 작업을 다시 승인할 때까지 끌어오기 요청을 병합할 수 없습니다. 대상 분기에 대한 자세한 내용은 "끌어오기 요청 정보"을(를) 참조하세요.

필요에 따라 코드 소유자의 검토를 요구할 수 있습니다. 이렇게 하면 코드 소유자가 있는 콘텐츠를 수정하는 끌어오기 요청은 해당 코드 소유자가 먼저 승인해야 보호된 분기에 병합할 수 있습니다. 코드 소유자가 여러 명인 경우 코드 소유자 중 누구라도 승인하면 이 요구 사항을 충족할 수 있습니다. 자세한 내용은 "코드 소유자 정보"을(를) 참조하세요.

필요에 따라 끌어오기 요청을 병합하기 전에 분기에 푸시할 마지막 사람이 아닌 다른 사용자의 승인을 요청할 수 있습니다. 즉, 하나 이상의 다른 권한이 있는 검토자가 변경 내용을 승인했습니다. 예를 들어 "마지막 검토자"는 최신 변경 세트가 다른 검토의 피드백을 통합하고 검토되지 않은 새 콘텐츠를 추가하지 않는다는 것을 검사할 수 있습니다.

많은 검토가 필요한 복잡한 끌어오기 요청의 경우, 마지막으로 푸시한 사람이 아닌 다른 사람의 승인을 요구하는 것은 모든 부실 검토를 해제할 필요가 없는 타협이 될 수 있습니다. 이 옵션을 사용하면 "부실" 검토가 해제되지 않으며, 가장 최근에 변경한 사람이 아닌 다른 사람이 승인하는 한 끌어오기 요청이 승인된 상태를 유지합니다. 끌어오기 요청을 이미 검토한 사용자는 이 요구 사항을 충족하기 위해 가장 최근의 푸시 후에 다시 승인할 수 있습니다. 끌어오기 요청이 "하이재킹"(승인되지 않은 콘텐츠가 승인된 끌어오기 요청에 추가됨)될 것이 우려되는 경우 부실 검토를 해제하는 것이 더 안전합니다.

필요에 따라 끌어오기 요청을 분기에 병합하기 전에 댓글을 모두 확인하도록 요청할 수 있습니다. 이렇게 하면 병합하기 전에 모든 댓글이 처리 또는 확인됩니다.

병합 전 상태 검사 통과 요구하기

필수 상태 검사는 협력자가 분기 또는 규칙 세트의 대상 태그를 변경하기 전에 필요한 모든 CI 테스트가 통과되었는지 확인합니다. 필수 상태 검사는 검사 또는 상태일 수 있습니다. 자세한 내용은 "상태 검사 정보"을(를) 참조하세요.

커밋 상태 API를 사용하여 외부 서비스에서 커밋을 적절한 상태로 표시할 수 있습니다. 자세한 내용은 "커밋 상태에 대한 REST API 엔드포인트"을(를) 참조하세요.

필수 상태 검사를 사용하도록 설정한 후에는 협력자가 변경 내용을 분기 또는 태그에 병합하기 전에 모든 필수 상태 검사를 통과해야 합니다. 옵션에서, 상태 확인 결과에 관계없이 분기 만들기를 허용하려는 경우 "생성 시 상태 확인 불필요"를 선택할 수 있습니다.

리포지토리에 대한 쓰기 권한이 있는 모든 사용자 또는 통합은 리포지토리에서 상태 검사의 상태를 설정할 수 있지만, 경우에 따라 특정 GitHub App의 상태 검사만 수락해야 할 수 있습니다. 필수 상태 검사 규칙을 추가할 때 상태 업데이트의 예상 원본으로 앱을 선택할 수 있습니다. 앱은 statuses:write 권한이 있는 리포지토리에 설치되어야 하고, 최근에 검사 실행을 제출해야 하며, 규칙 세트의 기존 필수 상태 검사에 연결해야 합니다. 다른 사용자 또는 통합에서 상태를 설정하면 병합이 허용되지 않습니다. "모든 원본"을 선택하면 병합 상자에 나열된 각 상태의 작성자를 수동으로 확인할 수 있습니다.

필수 상태 검사를 "loose" 또는 "strict"로 간주할 수 있습니다. 선택한 필수 상태 검사의 유형은 분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트해야 하는지 여부를 결정합니다.

필수 상태 검사 유형	설정	병합 요구 사항	고려 사항
엄격	병합 전 분기 업데이트 필요 확인란을 선택합니다.	주제 분기를 병합하기 전에 반드시 기본 분기의 최신 상태로 업데이트해야 합니다.	이는 필수 상태 검사의 기본 동작입니다. 다른 협력자가 대상 분기에 업데이트한 후 헤드 분기를 최신 상태로 만들어야 하므로 더 많은 빌드가 필요할 수 있습니다.
Loose	병합 전 분기 업데이트 필요 확인란을 선택하지 않습니다.	분기를 병합하기 전에 기본 분기의 최신 상태로 업데이트할 필요가 없습니다.	다른 협력자가 끌어오기 요청을 병합한 후 헤드 분기를 최신 상태로 만들 필요가 없으므로 필요한 빌드 수가 줄어듭니다. 기본 분기와 호환되지 않는 변경 내용이 있는 경우 분기를 병합한 후 상태 검사가 실패할 수 있습니다.
사용 안 함	병합 전 상태 확인 통과 필요 확인란을 선택하지 않습니다.	분기에 병합 제한이 없습니다.	필수 상태 검사를 사용하도록 설정하지 않은 경우 협력자는 기본 분기의 최신 상태인지 관계없이 언제든지 분기를 병합할 수 있습니다. 이렇게 하면 호환되지 않는 변경이 발생할 가능성이 증가합니다.

문제 해결 정보는 "필수 상태 검사 문제 해결"을(를) 참조하세요.

code scanning 병합 보호 설정

리포지토리가 code scanning(으)로 구성된 경우 규칙 집합을 사용하여 다음 조건 중 하나가 충족될 때 당겨받기 요청이 병합되지 않도록 할 수 있습니다.

• 필수 도구가 규칙 집합에 정의된 심각도에 대한 code scanning 경고를 발견했습니다.

• 필수 code scanning 도구의 분석이 아직 진행 중입니다.

• 필수 code scanning 도구가 리포지토리에 대해 구성되지 않았습니다.

자세한 내용은 "코드 검사 병합 보호 설정"을(를) 참조하세요. code scanning에 대한 일반적인 정보는 “코드 검사 정보”을(를) 참조하세요.

강제 푸시 차단

사용자가 대상 분기 또는 태그에 강제로 푸시하는 것을 방지할 수 있습니다. 이 규칙은 기본적으로 사용하도록 설정되어 있습니다.

다른 사람이 분기 또는 태그에 강제로 푸시하는 경우, 다른 협력자가 작업을 기반으로 한 커밋은 분기 또는 태그의 기록에서 제거될 수 있습니다. 병합 충돌 또는 손상된 끌어오기 요청으로 이어질 수 있습니다. 강제 푸시를 사용하여 분기를 삭제하거나 분기를 통해 끌어오기 요청에서 승인되지 않은 커밋을 가리킬 수도 있습니다.

강제 푸시를 사용하도록 설정해도 다른 규칙은 재정의되지 않습니다. 예를 들어 분기에 선형 커밋 기록이 필요한 경우 해당 분기에 병합 커밋을 강제 푸시할 수 없습니다.

사이트 관리자가 리포지토리의 모든 분기에서 강제 푸시를 차단한 경우 분기에 강제 푸시를 사용하도록 설정할 수 없습니다. 자세한 내용은 "엔터프라이즈에서 리포지토리 관리 정책 적용"을(를) 참조하세요.

사이트 관리자가 기본 분기에만 강제 푸시를 차단한 경우에도 다른 분기 또는 태그에 대해 강제 푸시를 사용하도록 설정할 수 있습니다.

병합하기 전에 워크플로를 거치도록 요구

끌어오기 요청을 통합하기 전에 워크플로를 전달하도록 조직 수준에서 규칙 집합 워크플로를 구성할 수 있습니다. 자세한 내용은 "조직에서 리포지토리에 대한 규칙 집합 만들기"을(를) 참조하세요.

규칙 세트 워크플로 구성 설정 문제 해결에 대한 자세한 내용은 "규칙 문제 해결"을 참조하세요.

워크플로 파일 사용

이 규칙을 사용하려면 먼저 워크플로 파일을 만들어야 합니다. 워크플로 파일은 실행하려는 리포지토리의 표시 유형과 일치하는 리포지토리에 있어야 합니다. 특히, 공용 워크플로는 조직의 리포지토리에서 실행되고, 내부 워크플로는 내부 및 프라이빗 리포지토리에서만 실행할 수 있으며, 프라이빗 워크플로는 프라이빗 리포지토리에서만 실행할 수 있습니다. 자세한 내용은 "워크플로 정보"을(를) 참조하세요.

워크플로 파일이 내부 또는 프라이빗 리포지토리에 있고 조직의 다른 리포지토리에서 워크플로를 사용하려는 경우, 리포지토리 외부에서 워크플로에 대한 액세스를 허용해야 합니다. 자세한 내용은 "내부 리포지토리의 구성 요소에 대한 액세스 허용" 또는 "프라이빗 리포지토리의 구성 요소에 대한 액세스 허용"을 참조하세요.

조직에서 규칙 세트에 이 규칙을 추가하면 원본 리포지토리와 적용하려는 워크플로를 지정하세요.

규칙 세트 워크플로에 "평가" 모드 사용

규칙 세트트 워크플로가 "평가" 모드에서 실행되고 통과하는 경우 규칙 세트 워크플로를 "활성" 모드로 설정하고 새 워크플로 실행을 트리거하지 않고 끌어오기 요청을 병합할 수 있습니다.

"평가" 모드에서 규칙 세트를 만들기 전에 끌어오기 요청을 열면 규칙 세트가 적용되지 않으므로 끌어오기 요청을 병합할 수 있습니다.

적용 상태에 대한 자세한 내용은 "리포지토리에 대한 규칙 세트 만들기"을 참조하세요.

지원되는 이벤트 트리거

규칙 집합 워크플로는 pull_request, pull_request_target 및 merge_group 이벤트 사용을 지원합니다. 따라서 워크플로가 규칙 집합에서 실행되도록 워크플로의 on: 섹션에서 이러한 이벤트 중 하나 이상을 지정해야 합니다.

지원되는 이벤트에 대해 지정한 필터는 무시됩니다(예: branches, branches-ignore, paths, types 등). 워크플로는 지원되는 이벤트의 기본 활동 유형에 의해서만 항상 트리거됩니다.

이벤트	기본 작업 유형
pull_request	opened, synchronize, reopened
pull_request_target	opened, synchronize, reopened
merge_group	checks_requested

규칙 세트 워크플로를 사용하여 특정 분기를 대상으로 지정

규칙 세트 워크플로가 끌어오기 요청 및 병합 큐 환경의 일부로 실행되므로 이 규칙을 적용하면 Direct Push가 차단됩니다. 따라서 리포지토리의 모든 분기를 대상으로 하는 규칙 세트에 이 규칙을 적용해서는 안 됩니다.

이 규칙은 분기의 모든 변경 내용이 끌어오기 요청에 의해 수행되는 분기를 대상으로 하는 규칙 세트에만 추가되어야 합니다.

옵션에서 상태 확인 결과에 관계없이 분기 만들기를 허용하려는 경우 "생성 시 워크플로 검사 불필요"를 선택할 수 있습니다.

메타데이터 제한

GitHub Enterprise 플랜의 조직은 추가 규칙에 액세스하여 커밋 메타데이터의 형식을 지정하는 방법을 제어할 수 있습니다. 리터럴 문자열 또는 정규식 구문을 사용하여 커밋 메타데이터가 준수해야 하는 패턴을 정의할 수 있습니다. 예를 들어 커밋 메시지가 GitHub 문제 번호를 포함하거나 커밋자 또는 작성자에게 이메일 주소가 @octoorg.com으로 끝나게 하도록 요청할 수 있습니다. 새 분기 이름 및 태그 이름의 형식을 제어할 수도 있습니다. 커밋 메타데이터에 유용한 정규식을 선택하려면 "리포지토리에 대한 규칙 세트 만들기"을 참조하세요.

기여자가 요구 사항을 충족하지 않는 커밋으로 분기 또는 태그를 업데이트하려고 하면 기여자에게 커밋에 무엇이 잘못되었는지 알려주는 오류가 표시됩니다. 이 오류는 명령줄, 사용자가 푸시할 때 및 GitHub.com에서 사용자가 끌어오기 요청을 커밋하거나 병합하려고 할 때 모두 나타날 수 있습니다. 커밋은 Git에서 변경할 수 없습니다. 기여자가 커밋을 만든 후에는 커밋의 메타데이터를 편집할 수 없으므로 리포지토리에 작업을 성공적으로 기여하기 전에 커밋 기록을 새 커밋으로 다시 쓰기 위해 다시 지정해야 할 수 있습니다.

메타데이터 제한은 분기 기록의 커밋 간에 일관성을 적용하는 데 유용합니다. 이는 기존 커밋 사양과 같은 모범 사례를 준수하거나 커밋 메타데이터를 사용하는 도구와 통합하는 데 유용할 수 있습니다. 예를 들어 각 메시지가 예측 가능한 형식을 준수하는 경우 커밋 메시지의 내용에 따라 스크립트를 실행하는 것이 더 쉬워집니다. 사용자 지정 수신 전 후크 스크립트를 설정하는 대신 메타데이터 제한을 사용할 수 있습니다. 자세한 내용은 "[AUTOTITLE] (/admin/policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks)."을 참조하세요.

메타데이터 제한에 대한 중요한 고려 사항

메타데이터 제한은 "ref 업데이트"를 차단합니다. 기여자가 요구 사항을 충족하지 않는 커밋을 포함하는 작업을 푸시하는 경우, 푸시가 거부되지 않지만 대상으로 하는 분기 또는 태그는 업데이트되지 않습니다. 기술적으로 커밋은 여전히 리포지토리를 입력합니다. 커밋은 "검색 가능"(리포지토리에서 탐색할 수 있음)하지만 "도달 가능"(분기 또는 태그의 기록에 연결되지 않음)합니다. 기여자의 푸시에 다른 분기 또는 태그에 대한 작업과 해당 분기 또는 태그의 요구 사항을 충족하는 커밋이 포함된 경우 해당 참조가 성공적으로 업데이트됩니다.

메타데이터 제한은 리포지토리에 기여하는 사용자에 대한 마찰을 증가시킬 수 있습니다. 일반적으로 메타데이터 제한을 적용하는 경우 제한된 분기 세트에서 이 작업을 수행하여 기여자의 일별 작업에 영향을 주지 않도록 해야 합니다. 예를 들어 기여자가 작동할 수 있는 모든 토픽 분기에 일관된 커밋 메시지 요청하는 대신 main에 대한 일관된 커밋 메시지만 요청한 다음 main에 끌어오기 요청을 요청합니다.

Squash 병합을 사용하는 경우, 병합 전에 메타데이터 제한이 평가되므로 끌어오기 요청의 모든 커밋이 요구 사항을 충족해야 합니다. 커밋자 이메일에 적용되는 메타데이터 제한의 경우, 제한을 충족하려면 Squash 병합에 대한 noreply@github.com이 패턴에 포함되어야 합니다.

기존 분기 또는 태그에 메타데이터 제한을 추가하면 해당 시점부터 분기 또는 태그로 푸시된 새 커밋에 대해 규칙이 적용되지만 분기 또는 태그의 기존 기록에 대해서는 적용되지 않습니다.

파일 경로 제한

지정된 파일 경로의 변경 내용이 포함된 커밋이 리포지토리에 푸시되지 않도록 합니다.

이 테스트에 fnmatch 구문을 사용할 수 있습니다. 예를 들어 test/demo/**/*를 대상으로 하는 제한은 test/demo/ 디렉터리의 파일이나 폴더에 대한 푸시를 방지합니다. test/docs/pushrules.md를 대상으로 하는 제한 사항은 test/docs/ 디렉터리의 pushrules.md 파일에 대한 푸시를 방지합니다. 자세한 내용은 "리포지토리에 대한 규칙 세트 만들기"을(를) 참조하세요.

파일 경로 길이 제한

지정된 문자 제한을 초과하는 파일 경로가 포함된 커밋이 리포지토리에 푸시되지 않도록 합니다.

파일 확장명 제한

지정된 파일 확장명의 파일이 포함된 커밋이 리포지토리에 푸시되지 않도록 합니다.

파일 크기 제한

지정된 파일 크기 제한을 초과하는 커밋이 리포지토리에 푸시되지 않도록 합니다.