[Git] Branch Ruleset 설정

(1) Branch Ruleset 생성 페이지

설정 페이지

 

GitHub의 레포지토리의 상단 탭에서

Settings - Branches 순으로 클릭하면

위 사진과 같은 페이지로 이동한다.

 

빨간색 동그라미로 된 Add branch ruleset을 클릭하면 된다.

우측의 Add classic branch protection rule은

Branch Ruleset이 나오기 이전의 브랜치 보호 규칙을 설정하는 기능이다.

 

브랜치 보호 규칙이 궁금하다면 아래 링크를 참고해 주세요!

 

[Git] Branch Protection Rule과 Branch Ruleset — Breaking Dev

[Git] Branch Protection Rule과 Branch Ruleset

 

---

(2) Branch Ruleset 생성 옵션

Ruleset Name, Enforcement Status, Bypass List

 

빨간 줄의 Ruleset Name은

브랜치 보호 규칙을 식별하기 위한 이름이다.

여러 규칙 집합을 관리할 때,

각 규칙 집합을 명확히 구분할 수 있기 위한 용도이다.

 

파란 줄의 Enforement Status는

브랜치 보호 규칙의 활성화 여부이다.

Active는 규칙이 활성화되어 해당 규칙이 브랜치에 적용됨을 나타내며,

Inactive는 규칙이 비활성화 되어 해당 규칙이 브랜치에 적용되지 않음을 나타낸다.

규칙을 적용 여부를 제어 가능하도록 하는 용도이다.

 

초록 줄의 Bypass List는

설정된 브랜치 보호 규칙을

우회할 수 있는 사용자 또는 팀 목록이다.

Bypass List에 포함된 사용자는 규칙을 무시하고

특정 브랜치에 Push하거나 Merge할 수 있다.

관리자나 팀 리더와 같이,

서로 다른 권한을 가진 사용자에게 규칙을 우회할 수 있기 위한 용도이다.

주로 긴급 상황이나 관리 목적으로 사용되는 것 같다.

 

Target Branch

 

Target branch는

PR(Pull Request) 또는 Merge 작업을 할 때,

변경 사항이 적용될 대상 브랜치이다.

 

예를 들어,

개발자가 feature/new-page 브랜치로 기능을 구현한 뒤,

해당 기능을 main 브랜치에 병합하기 위해 PR를 생성한다.

이 때, Target Branch는 main이 되는 것이다.

 

Branch Rules 01

 

Branch Rules는 브랜치 규칙을 설정하는 부분이다.

 

• Restrict creations
  • 특정 브랜치 이름 패턴을 허가된 사용자만 생성 가능하도록 제한
  • 예를 들어, feature/* 혹은 release/*와 같은 패턴의 브랜치 생성에 대한 제한을 설정
  • Bypass List에 등록된 사용자만 브랜치를 생성 가능
• Restrict updates
  • 특정 브랜치에 대해 업데이트를 제한
  • 해당 브랜치에 변경 사항을 푸시할 수 있는 사용자를 제한 가능
  • Bypass List에 등록된 사용자만 변경 가능
• Restrict deletions
  • 특정 브랜치에 대해 삭제 권한을 제한
  • main이나 develop처럼 중요한 브랜치의 삭제를 방지할 때 사용
  • Bypass List에 등록된 사용자만 브랜치 삭제 가능
• Require linear history
  • merge commit을 방지하고 직선형 히스토리를 요구
  • merge commit을 사용하지 않고, Squash 또는 Rebase 방식만 사용하여 병합 하도록 요구할 때 설정
  • 병합 히스토리가 더 깔끔하고 직선적이게 됨
• Require merge queue
  • merge queue를 사용하여 병합 작업을 관리
  • 여러 PR이 동시에 병합될 때 생기는 충돌, 문제를 예방하기 위한 기능
  • 해당 옵션 설정 시, 자동으로 병합 순서를 관리하는 큐 시스템을 통해 하나씩 병합 가능
• Require deployments to succeed
  • 선택한 배포 환경에서 성공적인 배포가 완료되어야만 변경 사항을 해당 브랜치에 푸시할 수 있도록 설정
  • 특정 환경(예: staging, production)에 배포가 성공적으로 이루어졌을 때만 병합을 허용하고자 할 때 사용
• Require signed commits
  • 푸시되는 모든 커밋은 GPG 서명 또는 SSH 서명을 요구
  • 보안을 강화하고, 커밋이 검증된 사람에 의해 작성되었음을 보장하기 위해 서명을 요구
• Require a pull request before merging
  • 모든 커밋이 PR을 통해 병합 되도록 요구
  • 팀 협업에서 직접 푸시를 방지하고, 반드시 PR 리뷰를 통해 코드 변경이 이루어지도록 강제하는 옵션
• Required approvals
  • Merge하기 위해 필요한 승인된 리뷰의 수를 설정
  • 예를 들어, PR을 병합하려면 최소 2명의 리뷰 승인이 필요하도록 설정 가능
• Dismiss stale pull request approvals when new commits are pushed
  • 새로운 커밋이 푸시되면 이전의 PR 승인을 무효화
  • 새로운 커밋이 추가되면 기존의 리뷰를 다시 확인하게 하여, 리뷰가 최신 상태로 유지되도록 하는 기능
• Require review from Code Owners
  • Code Owners가 지정된 파일에 대해 PR을 제출할 경우, 해당 Code Owners의 리뷰 승인을 요구
  • 중요한 파일을 담당하는 Code Owners가 변경사항을 검토하도록 요구
• Require approval of the most recent reviewable push
  • 최신 커밋이 다른 사람의 승인 없이 병합되지 않도록 설정
  • 커밋을 푸시한 사람 외의 다른 사람이 최신 커밋에 대해 승인을 해야 병합을 허용하는 규칙
• Require conversation resolution before merging
  • PR에서 모든 conversation 해결될 때까지 병합을 제한
  • 코드 리뷰 중 해결되지 않은 conversation이나 논의 중인 사항을 해결해야 병합할 수 있도록 하는 기능
• Request pull request review from CopilotPreview
  • 프리뷰 기능
  • *GitHub Copilot을 사용하여 자동 리뷰 요청을 설정할 수 있는 옵션

*GitHub Copilot: GitHub가 2021년 출시한 자동 코드 완성 인공지능이다. 코드 리뷰와 간결한 코드를 제안하고, 특정 디자인 패턴으로 설계 요청을 하면 바로 적용해주는 등의 기능을 가진 AI 기반 코드 작성 도구다.

 

Branch Rules 02

 

• Require status checks to pass
  
  • 상태 검사르 반드시 통과한 후에만 브랜치에 변경 사항을 병합하도록 강제하는 옵션
  • 병합 전에 지정된 상태 검사(예: CI/CD 빌드, 테스트)가 성공적으로 통과해야 함
• Block force pushes
  • 강제 푸시(git push --force)를 방지
  • 브랜치 히스토리를 덮어쓰는 강제 푸시를 방지하여 히스토리 손상을 막음
• Require code scanning results
  • *코드 스캐너의 결과가 성공적으로 제공되어야만 브랜치 업데이트가 허용
  • 예를 들어, 코드 스캔을 통해 보안 취약점 등을 점검하고, 결과가 성공적으로 나오기 전에는 병합을 차단

 

*코드 스캔 도구: 소스 코드의 품질, 보안, 성능, 버그 등을 자동으로 분석하는 도구다.

 

Restrictions

 

Restrictions는 브랜치에 대한 세부적인 제약 조건을 설정하는 부분이다.

GitHub Enterprise에서만 사용 가능하다.

 

• Restrict commit metadata
  • *커밋 메타데이터(작성자 이메일, 커밋 메시지 등)에 대한 제한을 설정
• Restrict branch names
  • 브랜치 이름에 대한 제약을 설정
  • 예를 들어, feature/*, bugfix/* 등과 같은 브랜치 이름 규칙을 설정

*커밋 메타데이터: Git 커밋에 포함된 부가적인 정보를 의미한다. 커밋 메시지가 아니라 커밋이 누가, 언제, 어디서 작성되었는지에 대한 정보 등을 포함한다.

 

---

(3) Create

브랜치 보호 규칙에 대한 옵션 설정을 끝마쳤다면

하단의 Create 버튼을 클릭하면 브랜치 보호 규칙이 생성된다.

 

띠용띠용

옵션이 참말로 많다.

하나씩 읽어보니 머리가 핑글핑글 도는 것 같다.

 

하지만 참여 중인 프로젝트에서는 모든 옵션을 사용하지는 않을 것이니

다행인지 어떤지는 모르겠다.

 

Restrict deletions으로 특정 브랜치에 대한 삭제 권한을 제한할 것이고,

Require a pull request before merging을 통해 직접적인 푸시를 방지하고 PR을 통해 병합하도록 제한할 것이며,

Block force pushes을 통해 명렁어로 강제 푸시를 하는 것을 방지할 것이다.

 

Branch Ruleset 생성 시

기본으로 체크되어있는 옵션을 제외하고

Require a pull request before merging만을 추가적으로 설정한 것이다.

 

옵션들을 전부 다 이해하진 못하였지만,

추후 다른 프로젝트에서 좀 더 복잡한 규칙도 설정하지 않을까 하여 우선 정리해 보았다.