깃허브 브랜치 룰

 

간단한? 협업할때 강제 푸쉬를 막고 원활하게 협업할 수 있게 도와주는 깃허브 룰셋팅에 대해 알아보자

 

아래는 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" }
    
    브랜치 기록이 꼬이는 것을 방지하고 협업을 원활하게 합니다.
  • 선형 히스토리 강제:
    { "type": "required_linear_history" }
    
    Merge 커밋 없이 Rebase 또는 Squash Merge만 허용하여 깔끔한 커밋 히스토리를 유지합니다.
  • 풀 리퀘스트 규칙:
    {
      "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. 요약

이 룰셋은 님들 레포지토리 저장소의 주요 브랜치를 보호하고 코드 품질을 유지하기 위해 아래의 규칙을 적용함

  • 브랜치 삭제 방지
  • 강제 푸시 방지
  • 선형 히스토리 유지
  • 풀 리퀘스트 및 코드 리뷰를 통한 변경 사항 관리

 

아무튼 푸쉬는 레포 주인인 나도 무서운 법...!