얼마 전 스터디를 통해 github에 branch protection rule에 대해 듣게 되었다.
그리고 이틀 뒤 깃허브 PR을 dev 브랜치가 아닌 main 브랜치에 머지하는 대참사가 발생했고,,,
알게 된 후, 바로 적용하지 않았던 것이 후회됐다,,,
그래서 branch protection rule에 대해 알아보고자 한다.
찾아보고 바로 적용하려 하니 생각보다 옵션이 굉장히 많았다! ㅎ
우선 Github에서 브랜치 룰을 적용하는 방법을 알아보자!
Protection rule 적용 방법
Github Repository 상단에 있는 Setting 탭으로 이동
그 후, 좌측 메뉴바에서 Branch 탭으로 이동한다.
Branch로 이동하게 되면 위 이미지에 나와있는 Add branch protection rule 버튼을 눌러 하단 이미지처럼 protection rule을 적용할 수 있다.
이제 각각의 항목에 대해 자세히 알아보자
Branch name pattern
특정 브랜치나 feat/***와 같이 특정 경로를 가진 브랜치에 적용할 수 있다.
// 특정 브랜치 적용
dev
// 특정 경로 브랜치 ('*'를 통해 feat/을 포함하는 모든 브랜치에 적용 가능)
feat/*Require a pull request before merging
다른 브랜치에 작업 후 PR을 요청해야만 해당 규칙이 활성화된 브랜치에 merge할 수 있다.
협업 시 로컬에서 직접적으로 commit을 push하는 것으로부터 보호하고 코드리뷰를 위해 사용한다.
Require status checks to pass before merging
Github에서 제공하는 REST API를 사용하여 커밋을 error나 failure, pending, success 등의 상태로 표시할 수 있는데, 설정한 상태 값을 통과하면 해당 브랜치에 병합할 수 있다.
Require conversation resolution before merging
PR에서 코드 리뷰 작성 후 생성되는 conversation이 모두 solved되었을 때에만 merge할 수 있다.
Require signed commits
Github GPG key를 발급 받은 사람이 커밋할 경우 Verified라는 마크가 붙은 커밋만 푸시할 수 있다. 자세한 사항은 공식문서를 참고하는 편이 좋을 것 같다.
Require linear history
히스토리 관리를 위해 해당 브랜치에서 분기처리를 할 수 없게 막는다. 문제가 발생했을 때 여러 개의 브랜치로 나눠지면 히스토리 추적이나 이전으로 되돌리기 어렵기 때문에 브랜치를 하나로 관리하고자 할 때 사용한다.
Require merge queue
merge queue는 merge가 가능할 때 자동으로 merge하는 것을 예약할 수 있는 기능이다. 해당 기능을 이용하여 merge한다.
Require deployments to succeed before merging
배포에 성공해야만 merge할 수 있다. 해당 저장소에 설정된 환경 중 배포 성공 확인 대상을 선택할 수 있다.
Lock branch
해당 브랜치에 push할 수 없게 읽기 전용으로 만든다.
Do not allow bypassing the above settings
관리자 권한을 가진 사람도 설정을 지키지 않으면 merge할 수 없도록 막는다.
Restrict who can push to matching branches
브랜치에 push할 수 있는 사람 또는 팀, 앱을 지정한다.
Allow force pushes
강제 push 허용 여부
Allow deletions
푸시 액세스 권한이 있는 사용자의 브랜치 삭제 허용 여부
해당 내용에 오류가 있을 시에는 꼭꼭 알려주세요,,,선생님들,,ㅜㅜ
부탁,,,드립니다,,,
