Your developer_v2 branch isn't protected: PR(Pull Request) 시, 브랜치 보호하기

 

default 브랜치를 변경하고, 깃허브 확인해보니 'Your developer_v2 branch isn't protected' 이런 경고창이 떴다. 

 

💡 메시지 뜨는 원인 

이게 뭔가 하고 봤더니 developer_v2 브랜치가 강제 푸시나 직접 푸시 등이 가능한 상태로, 보호되지 않는 상태라는 뜻이다. 

이 메시지는 주로 깃허브에서 PR(Pull Request) 머지할 때 나타나는 메시지로 깃허브에서 protected branch 설정을 하면 PR를 통해서만 코드가 병합되고, 직접 푸시를 막을 수 있다. 

 

👩🏻‍💻 Protect this branch 설정해보기 

1. GitHub 저장소(Repository)로 이동
2. Settings → Branches 선택
3. "Branch protection rules"에서 "Add branch protection rule" 클릭

 

- Ruleset Name : 적용할 Ruleset Name 설정 

- Enforcement status : Active (브랜치에 규칙 바로 적용됨) 

 

- Bypass list : 이 규칙에서 예외해야 하는 목록을 설정할 수 있음 

 

- Targets : 규칙을 적용할 목록을 설정하는 곳으로, 대상은 저장소나 브랜치를 대상으로 지정할 수 있음 

(우선 나는 Default 브랜치만 적용하도록 함) 

 

- Rules : 브랜치에 규칙을 지정하는 부분이다. 

 

Restrict creations
: 특정 브랜치에 대해 새로운 참조(refs)를 생성하는 것을 제한함 
-> 해당 브랜치에 새로운 브랜치를 생성하거나 태그를 추가하려면 "bypass permission"을 가진 사용자만 가능하게 됩니다

 

Restrict updates
: 특정 브랜치에 대한 업데이트를 제한함
-> "bypass permission"을 가진 사용자만 해당 브랜치에 푸시(push) 작업을 수행할 수 있음 

 

Restrict deletions ✅
: 특정 브랜치를 삭제하는 것을 제한함 
-> "bypass permission"을 가진 사용자만 해당 브랜치를 삭제할 수 있음

 

Require linear history
: 병합 커밋(merge commit)을 방지하고, 브랜치의 히스토리를 선형(linear)으로 유지함 
-> 병합 시 "squash" 또는 "rebase" 전략만 허용되며, 복잡한 히스토리 구조를 방지

 

Require deployments to succeed
: 특정 환경에 성공적으로 배포(deploy)된 후에만 브랜치에 푸시가 가능함 
-> 안정적인 배포 상태를 보장하고, 배포 실패 시 코드 변경을 차단함 

Require signed commits
: 해당 브랜치로 푸시되는 커밋은 반드시 서명이 검증된 상태여야 함. 
-> GPG 키 등을 사용하여 커밋의 신뢰성을 보장하며, 무단 변경을 방지함. 

Require a pull request before merging ✅
: 모든 커밋은 별도의 브랜치에서 작성되어야 하며, 풀 리퀘스트(Pull Request)를 통해 병합되어야 함.
-> 직접 푸시를 방지하고 코드 리뷰를 강제하여 품질 관리를 강화함 

Require status checks to pass
: 특정 상태 확인(Status Check)이 통과된 후에만 브랜치를 업데이트할 수 있음. 
-> CI/CD 테스트나 빌드 검증이 완료된 경우에만 변경 사항이 적용됨. 

Block force pushes ✅
: 강제 푸시(force push)를 금지함. 
-> 기존 커밋 히스토리가 덮어씌워지는 것을 방지하여 데이터 손실 위험을 줄임 

 

Require code scanning results
: 코드 스캐닝 도구의 결과가 확인된 후에만 브랜치를 업데이트할 수 있음 
-> 코드 품질 및 보안 문제를 사전에 탐지하여 안정성을 높임. 

 

 

적용할 Rule 들을 선택한 다음 create 하면 이렇게 Rule 이생성되는 것을 확인할 수 있다.