간단한? 협업할때 강제 푸쉬를 막고 원활하게 협업할 수 있게 도와주는 깃허브 룰셋팅에 대해 알아보자
아래는 json 파일로 다운받은 깃허브의 브랜치 룰이다.
{
"id": 1234567,
"name": "main-branch-protection",
"target": "branch",
"source_type": "Repository",
"source": "깃허브이름/레포지토리",
"enforcement": "active",
"conditions": {
"ref_name": {
"exclude": [
"refs/heads/*-temp/*",
"refs/heads/test/*"
],
"include": [
"~DEFAULT_BRANCH",
"refs/heads/main develop feature/* release/*"
]
}
},
"rules": [
{
"type": "deletion"
},
{
"type": "non_fast_forward"
},
{
"type": "required_linear_history"
},
{
"type": "pull_request",
"parameters": {
"required_approving_review_count": 1,
"dismiss_stale_reviews_on_push": true,
"require_code_owner_review": false,
"require_last_push_approval": true,
"required_review_thread_resolution": false,
"automatic_copilot_code_review_enabled": false,
"allowed_merge_methods": [
"merge",
"squash",
"rebase"
]
}
}
],
"bypass_actors": []
}
하나하나 설명을 해주자면
1. 기본 정보
- ID: 3626796 (GitHub 자동 할당)
- 이름: main-branch-protection
- 대상: branch (브랜치 보호)
- 소스 유형: Repository
- 소스 저장소: 깃허브이름/레포지토리
- 상태: active (활성화됨)
2. 적용 대상 브랜치 (conditions)
- 제외 (ref_name.exclude): 다음 패턴과 일치하는 브랜치는 이 룰셋에서 제외됩니다.
- refs/heads/*-temp/*: 이름 중간에 -temp가 포함된 임시 브랜치 (예: feature/add-login-temp).
- refs/heads/test/*: test/로 시작하는 테스트 브랜치 (예: test/unit-tests).
- 포함 (ref_name.include): 다음 패턴과 일치하는 브랜치에 이 룰셋이 적용됩니다.
- ~DEFAULT_BRANCH: 저장소의 기본 브랜치 (일반적으로 main 또는 master).
- refs/heads/main: main 브랜치.
- refs/heads/develop: develop 브랜치.
- feature/*: feature/로 시작하는 기능 개발 브랜치.
- release/*: release/로 시작하는 배포 준비 브랜치.
3. 규칙 (rules)
- 삭제 금지:
브랜치가 실수로 삭제되는 것을 방지합니다.{ "type": "deletion" }
- 강제 푸시 금지:
브랜치 기록이 꼬이는 것을 방지하고 협업을 원활하게 합니다.{ "type": "non_fast_forward" }
- 선형 히스토리 강제:
Merge 커밋 없이 Rebase 또는 Squash Merge만 허용하여 깔끔한 커밋 히스토리를 유지합니다.{ "type": "required_linear_history" }
- 풀 리퀘스트 규칙:
{ "type": "pull_request", "parameters": { "required_approving_review_count": 1, "dismiss_stale_reviews_on_push": true, "require_code_owner_review": false, "require_last_push_approval": true, "required_review_thread_resolution": false, "automatic_copilot_code_review_enabled": false, "allowed_merge_methods": [ "merge", "squash", "rebase" ] } }
- required_approving_review_count: 1: 풀 리퀘스트를 Merge하려면 최소 1명의 승인이 필요합니다.
- dismiss_stale_reviews_on_push: true: 새로운 변경 사항이 푸시되면 이전 리뷰를 무효화합니다.
- require_code_owner_review: false: 코드 소유자의 리뷰는 필수로 요구하지 않습니다.
- require_last_push_approval: true: 마지막 푸시 후에도 승인을 받아야 Merge할 수 있습니다.
- required_review_thread_resolution: false: 리뷰 스레드를 모두 해결하지 않아도 Merge할 수 있습니다.
- automatic_copilot_code_review_enabled: false: 자동 Copilot 코드 리뷰는 비활성화되어 있습니다.
- allowed_merge_methods: ["merge", "squash", "rebase"]: Merge, Squash, Rebase 방법을 모두 허용합니다.
4. 우회 액터 (bypass_actors)
- []: 현재 이 룰셋을 우회할 수 있는 액터 (사용자, 팀, 앱)는 없습니다.
5. 요약
이 룰셋은 님들 레포지토리 저장소의 주요 브랜치를 보호하고 코드 품질을 유지하기 위해 아래의 규칙을 적용함
- 브랜치 삭제 방지
- 강제 푸시 방지
- 선형 히스토리 유지
- 풀 리퀘스트 및 코드 리뷰를 통한 변경 사항 관리
아무튼 푸쉬는 레포 주인인 나도 무서운 법...!
'Today I learned' 카테고리의 다른 글
Anything LLM vs. LangChain 비교 (0) | 2025.02.10 |
---|---|
DRF와 FastAPI의 주요 차이점과 장단점 (0) | 2025.02.06 |
[프로그래머스-SQL]노선별 평균 역 사이 거리 조회하기 (0) | 2025.02.05 |
플랫폼별 OAuth 키 발급 방법 (0) | 2025.02.04 |
Django SECRET_KEY 환경변수로 안전하게 관리하기 (0) | 2025.02.03 |