Branch Protection rules
브랜치 보호에 대한 개념과 필요한 이유 및 설정방법에 대해 기술한 페이지
Last updated
브랜치 보호에 대한 개념과 필요한 이유 및 설정방법에 대해 기술한 페이지
Last updated
일반적으로 github를 통한 협업시 main
/master
브랜치는 프로젝트의 메인이 되는 형상을 보관하는 중요한 브랜치이며 각 개발자는 main
브랜치의 내용을 바탕으로 프로젝트를 시작하여 최종적으로 main
브랜치에 코드를 병합하여 어플리케이션을 완성할 것이다.
즉 main
브랜치로의 코드 병합은 각 개발자의 검토(review)과정을 통해 신중하게 진행되어야 한다.
하지만 개발자의 실수로 인해 main
-> origin/main
으로의 push
나 feature/1
-> origin/main
로의 push로 main
브랜치의 형상이 달라진다면 이를 공유해서 사용하고 있는 다른 개발자들은 예상치 못한 변경사항에 대해 인지 하지 못하고 있다가, 병합(merge)시 충돌(conflict)이 발생하거나 잘못된 프로세스로 인한 프로그램의 작동오류로 연결될 수 있다.
따라서 애초에 PR없는 main
브랜치로의 merge
는 원천 차단할 필요가 있고 이 기능은 Branch Protection rules로 설정 가능하다.
브랜치 보호를 위한 규칙들을 정의하는 공간.
Settings- Branches - Add branch ruleset에서 설정 가능하다.
현재 문서에서는 main브랜치로의 직접적인 push를 방지하는 rule에대해서만 다룰 예정이다.
RulesetName : rule의 이름을 적는다.
Enforcement status : 현재 룰의 활성화 여부. Active로 전환해야 Rule이 적용된다.
Bypass list : 현재 rule의 규칙에서 우회 할 수 있는 사용자를 추가하는 공간. main의 푸시는 모든 사용자에 대해 빠짐없이 규칙을 적용시킬 예정이라 추가할 필요 없다.
브랜치 보호 룰을 적용할 target 브랜치를 설정한다.(정규식 패턴 지정가능)
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
가 발생했다면 승인을 무효화하는 설정.
보호규칙을 추가한 후 로컬 main
에서 원격 main
으로의 push
는 더 이상 불가능하다. main
에 내가 원하는 소스코드를 병합하기 위해서는 작업용 브랜치 생성 후 작업용 브랜치로부터 PR을 통해 merge
해줘야한다.
PR 요청후 Review
를 통해 해당 커밋에 대한 승인을 완료해야 merge
가 가능하다
1) Files changed로 이동하여 코드의 수정사항을 검토한 후
2) Review Changes버튼을 눌러 코드에 대한 리뷰를 남기고,
3) Approve를 체크한 상태로 저장을 해야 승인이 완료된다. 이때 본인의 PR에는 승인을 할 수 없으므로 다른 팀원이 검토 후 승인을 해줘야 한다.