GitHub 브랜치 보호 일괄 전환, 기존 규칙은 남길까?

일괄 전환의 범위는 한 저장소다

10월 20일 추가된 기능은 저장소의 브랜치 보호 규칙을 한꺼번에 ruleset으로 옮긴다. 저장소 Settings → Rulesets에서 Import branch protection rules를 선택하면 생성할 규칙을 미리 볼 수 있다. GitHub 발표는 이미 기존 ruleset으로 보호되는 항목도 확인할 수 있다고 설명한다.

이름에 ‘일괄’이 들어가지만 조직의 모든 저장소를 자동 이전하는 기능은 아니다. 확인 창에서 생성 대상을 고르고 적용 상태를 선택한 뒤, 원래 브랜치 보호 규칙을 남길지 삭제할지 결정한다.

보호 규칙 하나가 ruleset 여러 개로 바뀔 수 있다

전환 전후 개수가 같아야 정상인 것은 아니다. 전환 문서는 한 ruleset으로 표현할 수 없는 보호 설정이 있으면 여러 개를 제안한다고 설명한다. 생성 전에 이름과 동작 변경 경고를 검토할 수 있다.

숫자보다 확인해야 할 것은 어떤 브랜치에 적용되고 누가 예외적으로 우회할 수 있느냐다. 관리자·팀·GitHub App이 기존에 하던 작업을 새 설정에서도 수행할 수 있는지 확인하는 편이 좋다. 전환 화면의 경고를 읽지 않은 채 생성 개수만으로 동등성을 판단해서는 안 된다.

별도로 JSON을 보관하거나 다른 저장소로 가져갈 계획도 있다면 우회 목록을 따로 확인해야 한다. ruleset 관리 문서는 이력에서 내보낸 JSON에 bypass 목록이 포함되지 않는다고 명시한다. 이는 JSON 내보내기의 범위이며, 일괄 전환이 우회 권한을 무조건 없앤다는 뜻은 아니다.

기존 규칙을 남기면 새 규칙과 함께 적용된다

원본을 보존하면 해당 브랜치는 기존 보호와 Active ruleset을 모두 만족해야 한다. 규칙 중첩 설명에 따르면 ruleset에는 우선순위가 없으며, 같은 규칙이 여러 조건으로 정의되면 가장 엄격한 조건이 적용된다.

따라서 승인 수를 줄인 새 ruleset을 만들었다고 기존의 더 높은 승인 조건까지 낮아지는 것은 아니다. 반대로 원본을 삭제하고 새 규칙을 꺼 두면, 그 두 설정으로는 보호가 이어지지 않는다. 별도로 적용되는 조직 규칙이 있는지도 함께 봐야 한다.

Evaluate는 위반을 기록하지만 막지는 않는다

Enterprise Cloud 문서의 Evaluate는 규칙을 강제하지 않고, 규칙을 적용했다면 위반으로 판정됐을 동작을 Rule Insights에 보여주는 상태다. 이 옵션이 제공되는 환경에서는 기존 보호를 남긴 채 새 정책의 영향을 살피는 데 활용할 수 있다. Active는 즉시 강제하고, Disabled는 강제도 평가도 하지 않는다.

ruleset 생성·수정에는 저장소 관리자 또는 edit repository rules 권한이 필요하다. 공개 저장소는 Free에서도 지원하지만 비공개 저장소 지원은 Pro·Team·Enterprise Cloud 등 요금제 조건을 따른다. 모든 계정에 같은 평가 옵션이 있다고 전제해서는 안 된다.

실무 순서는 명확하다. 미리보기에서 대상과 예외를 확인하고, 제공되는 적용 상태를 선택한 다음, 새 규칙이 의도대로 작동하는지 살핀다. 원본 삭제는 생성 버튼을 누른 사실이 아니라 새 보호의 실제 동작을 기준으로 결정해야 한다.

자주 묻는 질문