[Github] Branch protection rule 의미 분석

 

이번 포스팅은 사내에 PR을 통한 코드 리뷰 도입으로 git 브랜치에 직접적인 push 또는 merge를 제한하기 위한 옵션을 설정하던 중 branch protection rule의 의미를 나름대로 분석해보고 정리한 글입니다.

 

주관적인 의견이 들어갔을 수 있습니다. 틀린 부분에 대한 피드백은 환영합니다.

 

Github docs

https://docs.github.com/ko/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches

 

---

Protect matching branches

---

Require a pull request before merging

• 브랜치에 직접직인 푸시 및 병합을 제한합니다.
• PR을 통해서만 리모트 저장소에 새로운 코드를 병합할 수 있습니다.

 

Require approvals

• 새로운 코드가 병합되려면 PR에 대한 승인이 n개 이상 있어야 합니다. (n: 1 ~ 6 설정 가능)
• 승인이 n개 이상 떨어지지 않으면 PR을 리모트 저장소에 병합할 수 없습니다.

 

Dismiss stale pull request approvals when new commits are pushed

• PR 생성 후 동일한 브랜치에 추가적인 커밋이 푸시될 경우 기존 승인을 해제합니다.
• 테스트 결과 승인 후 추가적인 푸시가 발생하면 merge가 비활성화 되는 것은 같지만, 옵션을 활성화하면 리뷰어의 승인이 사라집니다.

PR 승인

추가 푸시 발생 - 옵션 비활성화일 경우

추가 푸시 발생 - 옵션 활성화일 경우

 

Require review from Code Owners

• 리뷰어 중 'Code Owners' 권한을 가진 사용자가 반드시 코드를 리뷰하도록 강제합니다.

 

Restrict who can dismiss pull request reviews

• 다른 리뷰어의 리뷰를 누락(dismiss)시키는 것을 방지합니다.
• 옵션을 비활성화하면 PR의 리뷰어가 다른 리뷰어의 리뷰를 해제할 수 있습니다.

 

Allow specified actors to bypass required pull request

• 사용자 또는 팀을 지정하여 브랜치에 직접 푸시 및 병합할 수 있는 권한을 부여합니다.

 

Require approval of the most recent reviewable push

• 오픈된 PR이 있는 브랜치로 새로운 푸시가 발생하면 해당 브랜치의 가장 최근 커밋에 대해 적어도 한 명 이상의 리뷰어가 승인을 해야 메인 브랜치에 병합이 가능해집니다.

 

Require status checks to pass before merging

• 코드가 병합되기 전에 CI/CD 빌드, 유닛 테스트, 정적 분석 등의 지정된 상태 검사가 성공해야 합니다.

 

Require conversation resolution before merging

• 코드가 병합되기 전 PR에 달린 리뷰가 모두 해결되어야 합니다.
• 코드 작성자는 리뷰어가 남긴 코멘트에 대해 'Resolve conversation' 버튼으로 해결됨을 표시할 수 있는데 모든 코멘트에 대해 이를 수행해야 병합이 가능합니다.

 

Require signed commits

• 코드 변경사항이 커밋될 때 GPG 서명이 필요합니다.

 

Require linear history

• 코드를 병합할 때 Squash merging 또는 Rebase merging 할 수 있도록 강제합니다.
• 리모트 저장소의 커밋 이력을 단순하게 유지할 수 있으며, 이력 되돌리기 등을 수행할 때 효율적으로 반영할 수 있습니다.

 

Require deploments to succeed before merging

• 코드가 병합되기 전 배포가 성공해야 합니다.

 

Lock branch

• 브랜치를 read-only 상태로 변경합니다.
• PR을 포함하여 푸시 및 병합이 불가능합니다.

 

Do not allow bypassing the above settings

• 관리자(Admin)도 예외 없이 위의 설정을 반영하며 PR을 통해서만 해당 브랜치에 병합할 수 있습니다.

 

Restrict who can push to matching branches

• 브랜치에 푸시할 수 있는 권한을 제한합니다.
• 특정 사용자 및 팀에게만 푸시 권한을 부여하며 다른 사용자는 푸시할 수 없습니다.
• Require a pull request before merging 옵션을 활성화 하였다면, 해당 옵션은 적용되지 않습니다.

 

 

 

Rules applied to everyone including administrators

---

Allow force pushes

• 브랜치의 기존 커밋 이력을 무시하고 새로운 커밋을 푸시하는 작업을 허용합니다.
• 이 옵션은 커밋 이력 무결성 관리에 영향을 미칠 수 있기 때문에 개발 및 테스트 단계에서만 사용하고 운영 단계에서는 비활성화 해야 합니다.

Allow deletions

• 브랜치에 푸시 권한이 있는 사용자가 해당 브랜치를 삭제할 수 있도록 허용합니다.

 

 

 

마치며

---

브랜치 보호 규칙을 적용해야 개발 또는 운영 브랜치에 잘못된 코드가 병합되는 것을 방지할 수 있습니다.

 

저는 PR을 통해서 리뷰어의 검토 후에 코드가 반영될 수 있도록 팀 내 문화를 도입하는 것을 목표로 두고 브랜치 관리 방법을 알아보았는데, Github에 명시된 설명만으로는 잘 이해가 되지 않아 직접 테스트를 해보며 확인하였습니다.

 

옵션에 대한 태스트는 주관적으로 진행하였기 때문에 정확하지 않은 정보가 있을 수 있고, 또 모든 옵션을 테스트해보진 못하였습니다.

 

글에 대한 피드백은 댓글로 남겨주시면 확인하고 수정하겠습니다 🤣

 

읽어주셔서 감사합니다.