깃허브를 사용하면서 다양한 사용방법에 대해 종종 포스팅하려고 한다.
프로젝트의 팀장을 하게 되면, 보통 내가 repository를 파고 브랜치 관리를 하게 되는데,
보통의 브랜치 전략으로
- main
- develop
- feature
- hotfix 등의 브랜치를 사용한다.
main은 배포용 브랜치로,여기다 직접 PR하거나 변경이 일어나면 안 된다.
따라서 일반적으로 feature에서 기능을 작업하고, develop에 PR하고, develop에서 문제가 없을 경우 main에 올리는 전략을 사용한다.
일반적으로 사용되는 브랜치 전략에 대해서는 나중에 포스팅 해 보려고 한다.
⭐develop나 main에 마음대로 변경이 가능하다면?
코드 리뷰 없이 들어간다면 제대로 작동하지 않는 코드, 버그가 들어간다고 해도 확인하기 어렵다.
그리고 code convention 규정을 통해 작업하는데, PR 승인 과정을 거치지 않는다면, 제대로 code convention 규정이 지켜지지 않은 코드가 들어갈 수 있다.
테스트되지 않은 코드가 바로 반영되며, main 브랜치에 적용될 경우 배포 중인 서비스에 치명적인 문제가 생길 수 있다.
따라서 Branch Protection 설정을 하여 main,develop 등의 중요 브랜치를 보호할 것이다.
📍Branch Protection이란?
브랜치 보호 규칙(Branch Protection Rules)은 중요 브랜치(main, develop 등)에 대한 무분별한 코드 변경을 막고, 코드 품질을 유지하기 위한 GitHub의 기능이다.
주요 보호 규칙 설정:
- Require pull request reviews: PR 병합 전 필수 리뷰어 수 지정
- Dismiss stale pull request approvals: 새로운 커밋 발생 시 기존 승인 초기화
- Require review from Code Owners: 코드 오너의 리뷰 필수화
- Require status checks: CI/CD 빌드 통과 필수화 (예: Jenkins 빌드 성공)
- Include administrators: 관리자도 동일한 규칙 적용
- Restrict direct pushes: 브랜치에 직접 push 금지
보호 규칙이 없다면?
- 코드 리뷰 없이 버그가 포함된 코드가 병합될 위험
- 팀의 코드 컨벤션이 지켜지지 않을 수 있음
- 테스트되지 않은 코드가 바로 배포될 수 있어 서비스 안정성 위협
등의 문제가 생길 수 있다. 직접 깃허브에서 설정해 보자.
깃허브에서 Branch Protection 설정하기
프로젝트의 관리자라면, setting 메뉴가 보인다.
Settings -> Branches 으로 들어간다.
그럼
Branch protection rules 가 보인다.
- Branch name pattern 에서 적용할 브랜치를 적는다.
- develop
- 아래의 Protect matching branches 을 설정한다.
항목에 대한 설명
(1)Require a pull request before mergin
을 체크하면, 모든 코드 변경은 반드시 PR(pull Request)를 통해서만 가능하다.
보호된 브랜치에 직접적인 푸시나 커밋은 불가능하고, PR을 통해서 접근해야 안전하므로
main, develop의 경우에 체크해준다.
(2)Require approvals
PR 병합 전 지정된 수의 승인이 필요하도록 한다.
PR전 최소한 n명의 팀원이 승인하도록 하는 것으로, 안정적인 코드 평가를 위해
develop 브랜치에 3명으로 설정하였다.
승인 없이는 병합할 수 없다.
(3)Dismiss stale pull request approvals when new commits are pushed
PR이 승인된 후 새로운 커밋이 추가되면 기존 승인이 자동으로 취소되도록 한다.
(4)Require review from Code Owners
ODEOWNERS 파일에 지정된 코드 담당자의 승인이 반드시 필요하도록 하여, 특정 파일이나 디렉토리에 대한 전문가의 승인을 보장한다.
(5)Require approval of the most recent reviewable push
자신이 푸시한 코드는 자신이 승인할 수 없다.
따라서 본인이 push 하면, 다른 사람의 승인이 필요.
(6)Require status checks to pass before merging
CI/CD 파이프라인의 상태 검사(테스트, 빌드 등)을 통과해야 한다.병합 전 상태검사를 통과해야 PR 병합이 가능하도록 한다.
(7) Require conversation resolution before merging
PR의 모든 코드 리뷰 대회가 해결되어야 병합 가능하고, 미해결된 토론이나 피드백이 있으면 병합 불가능하도록 한다.
우리의 devleop 브랜치는
- Require a pull request before merging
- Require approvals : 3
만 설정해 두었다.
그리고 lock branch를 설정해 주었는데,
🔒lock branch
Lock branch 설정으로
브랜치에 직접적인 push를 막고
PR을 통한 정상적인 병합 프로세스는 여전히 가능하여
즉, PR → 승인 → 병합의 과정은 정상적으로 작동하도록 할 수 있다.
따라서 해당 3개 설정만 기본적으로 작용하여 develop 브랜치 protection을 완료하였다.'
🖋️branch protection 을 하는 데 참고한 블로그
Branch Protect rule 설정
