📌 배경
팀 프로젝트 회고와 세미나 발표를 하며, 이런 문제를 정리한 적이 있다.
“기능은 만들었지만, 시너지는 만들지 못했다.”
(👉 회고 보기)
그 원인 중 하나가 피드백 루틴의 부재였다.
코드 리뷰 없이 병합되거나, 팀원의 작업 내용을 모른 채 개발이 진행되는 상황이 반복됐다.
👉 그래서 GitHub의 Ruleset 기능을 활용해 브랜치 병합 보호 설정을 적용해봤다.
우리는 main / dev / 작업 브랜치 구조로 작업하고 있으며, 이 글은 dev 브랜치 보호 설정에 대한 튜토리얼이다.
✅ 기대 효과
- 실수로 dev 브랜치 삭제 방지
- 리뷰 없이 merge 방지
- force push 방지
- 팀원 간 코드 리뷰 기반의 협업 문화 강화
이런 설정은 팀원 간 실수를 보완하고, 코드 리뷰 시스템을 강제해준다.
중요한 브랜치는 반드시 보호 룰을 걸어두자.
🔧 설정 방법
1. 저장소 진입 후 Settings 탭 클릭
2. 사이드바에서 Rules 클릭
3. 상단 탭에서 Rulesets 클릭
4. New ruleset 버튼 클릭
5. 룰셋 이름 입력
룰셋 이름은 자유롭게 지정하되, 식별이 쉬운 이름(Protect dev) 추천.
6. bypass 추가 클릭
7. 리포지토리 관리자 추가
rule을 우회할 수 있는 사용자 추가
Include by pattern 선택
9. 패턴 이름에 dev 입력
와일드카드 등 패턴 설정 가능 (예: dev, release/)
10. Restrict deletions 체크
dev 브랜치 삭제 방지
11. Require a pull request before merging 체크
PR을 통해서만 병합 가능. 직접 push 금지
Required approvals로 최소 승인자 수 설정 (팀 규모에 맞는 숫자 입력)
12 Block force pushes 체크
강제 푸시 방지 (git push --force 막음)
13. 하단의 Save changes 클릭
설정 완료! 🎉
🚀 워크플로우
- 기능 브랜치 생성: feature/login-system
- 코드 작성 및 커밋: 작업 완료 후 push
- Pull Request 생성: feature/login-system → dev
- 코드 리뷰: 팀원이 코드 검토 및 피드백
- 승인: 설정한 수만큼 승인 완료
- 병합: PR이 dev 브랜치로 병합
⚠️ 주의 사항
- Ruleset 설정 권한은
Admin만 가능 - 이미 force push가 된 브랜치에는 소급 적용 ❌
- PR 없이 작업해야 하는 예외 케이스가 있다면,
Bypass예외 유저 설정 필요
참고 자료
일잘러가 되어야지