GitHub의 Branch Rules에 변경 사항이 생겨서 새로 정리해 보았습니다.

아래는 각 규칙과 해당 기능에 대한 설명입니다.

---

1. Branch Rules 종류 및 설명

규칙	설명	주요 용도
Restrict creations	브랜치 생성 제한	무분별한 브랜치 생성 방지
Restrict updates	브랜치 업데이트 제한	권한 없는 사용자의 직접 푸시 방지
Restrict deletions	브랜치 삭제 제한	중요 브랜치 보호
Require linear history	선형 히스토리 강제	깔끔한 Git 히스토리 유지
Require merge queue	병합 큐 사용 강제	체계적인 병합 순서 관리
Require deployments to succeed	배포 성공 요구	안정적인 배포 보장
Require signed commits	서명된 커밋 요구	커밋 출처 신뢰성 확보
Require a pull request before merging	직접 커밋 제한, PR 강제	코드 품질을 보장
Require status checks to pass	상태 확인 통과 필요	자동화된 테스트/빌드 검증
Block force pushes	강제 푸시 차단	Git 히스토리 보호
Require code scanning results	코드 스캔 결과 요구	보안 취약점 사전 탐지

규칙	설명	주요 용도
Dismiss stale pull request approvals when new commits are pushed	새 커밋 시 기존 승인 취소	최신 코드 검토 보장
Require review from Code Owners	코드 소유자의 승인 필요	책임자의 검토 보장
Require approval of the most recent reviewable push	최신 푸시에 대한 승인 필요	변경 사항 검증 강화
Require conversation resolution before merging	모든 대화 해결 필요	논의 사항 완료 보장
Request pull request reivew from Copilot	Copilot 자동 리뷰 요청	AI 기반 코드 리뷰

---

2. Require a pull request before merging vs Restrict updates

Require a pull request before merging와 Restrict updates는 기능적으로 일부 겹치는 부분이 있다.

하지만, 서로 다른 용도로 사용된다.

---

가. 목적

• Require a pull request before merging의 역할:

구분	내용
주요 기능	브랜치에 직접 커밋이나 병합하는 것을 금지하고, 모든 변경 사항은 반드시 Pull Request(PR)를 통해 이루어지도록 강제합니다.
보호 수준	코드를 병합하려면 PR 프로세스를 거치고 승인(및 기타 조건 충족)이 필요하므로, 코드 리뷰 프로세스가 보장됩니다.

• Restrict updates의 역할:

구분	설명
주요 기능	브랜치를 업데이트(커밋, 병합 등)할 수 있는 사용자를 제한합니다. PR로의 병합 여부와 관계없이, 특정 사용자가 브랜치를 업데이트하지 못하도록 완전히 차단할 수 있습니다.
보호 수준	권한이 없는 사용자가 어떤 방식으로든 브랜치에 영향을 주는 것을 방지합니다.

---

나. 비교 

규칙	필요성	설명
Require a pull request before merging	매우 필요	PR을 강제하여 코드 리뷰 프로세스와 품질 관리를 보장함.
Restrict updates	조건부 필요	특정 사용자가 브랜치를 업데이트하지 못하도록 제한하려는 경우 추가로 필요.

• 협업 팀 환경 : Require a pull request before merging만 설정하면 충분.
• 보안이 매우 중요한 프로젝트 : Restrict updates를 함께 설정하여 보다 강력한 제어를 적용.

Require a pull request before merging는 협업 환경에선 기본적으로 사용하자.

반면, Restrict updates는 특정 사용자가 브랜치를 업데이트할 수 없도록 제한하는 특수한 용도로 사용하자.

---