Branch Protection rules

브랜치 보호에 대한 개념과 필요한 이유 및 설정방법에 대해 기술한 페이지

Intro

일반적으로 github를 통한 협업시 main/master 브랜치는 프로젝트의 메인이 되는 형상을 보관하는 중요한 브랜치이며 각 개발자는 main브랜치의 내용을 바탕으로 프로젝트를 시작하여 최종적으로 main브랜치에 코드를 병합하여 어플리케이션을 완성할 것이다.

main브랜치로의 코드 병합은 각 개발자의 검토(review)과정을 통해 신중하게 진행되어야 한다.

하지만 개발자의 실수로 인해 main -> origin/main으로의 pushfeature/1 -> origin/main 로의 pushmain브랜치의 형상이 달라진다면 이를 공유해서 사용하고 있는 다른 개발자들은 예상치 못한 변경사항에 대해 인지 하지 못하고 있다가, 병합(merge)충돌(conflict)이 발생하거나 잘못된 프로세스로 인한 프로그램의 작동오류로 연결될 수 있다.

따라서 애초에 PR없는 main브랜치로의 merge는 원천 차단할 필요가 있고 이 기능은 Branch Protection rules로 설정 가능하다.

Branch Protection rules

  • 브랜치 보호를 위한 규칙들을 정의하는 공간.

  • Settings- Branches - Add branch ruleset에서 설정 가능하다.

  • 현재 문서에서는 main브랜치로의 직접적인 push를 방지하는 rule에대해서만 다룰 예정이다.

Active로 해야된다
  • RulesetName : rule의 이름을 적는다.

  • Enforcement status : 현재 룰의 활성화 여부. Active로 전환해야 Rule이 적용된다.

  • Bypass list : 현재 rule의 규칙에서 우회 할 수 있는 사용자를 추가하는 공간. main의 푸시는 모든 사용자에 대해 빠짐없이 규칙을 적용시킬 예정이라 추가할 필요 없다.

여기 클릭

브랜치 보호 룰을 적용할 target 브랜치를 설정한다.(정규식 패턴 지정가능)

main선정

Protection rules들 중에서 아래만 선택

  • Require a pull request before merging : main 브랜치에 merge 하기 전에 반드시 PR을 해야한다는 설정. 즉 main으로의 직접적인 push를 막을수 있다.

  • Required approvals : merge에 필요한 승인 회수. 각 참여자는 Review를 통해 PR승인처리 할 수 있다.

  • Dismiss stale pull request approvals when new commits are pushed : PR에 승인을 했더라도 merge를 요청한 브랜치에서추가 push가 발생했다면 승인을 무효화하는 설정.

Rules Rulesets에서 생성된 rule들 확인/수정/삭제/추가 가능함

룰 설정 후 main->origin/main push error

보호규칙을 추가한 후 로컬 main에서 원격 main으로의 push는 더 이상 불가능하다. main에 내가 원하는 소스코드를 병합하기 위해서는 작업용 브랜치 생성 후 작업용 브랜치로부터 PR을 통해 merge해줘야한다.

PR생성후 화면. 붉은 글씨로 merge가 blocked 된것을 확인해 볼 수 있다.

PR 요청후 Review를 통해 해당 커밋에 대한 승인을 완료해야 merge가 가능하다

1) Files changed로 이동하여 코드의 수정사항을 검토한 후

2) Review Changes버튼을 눌러 코드에 대한 리뷰를 남기고,

3) Approve를 체크한 상태로 저장을 해야 승인이 완료된다. 이때 본인의 PR에는 승인을 할 수 없으므로 다른 팀원이 검토 후 승인을 해줘야 한다.

Branch Protection Rules 상세규칙 분석

Last updated