브랜치 전략(git flow) - 필수 Workflow, 보호 전략

진행하던 프로젝트를 더욱 고도화시키기 위한 기반 작업 중 하나로, github 브랜치 전략과 브랜치 보호 기능을 설정하기로 하였다.

 

브랜치 전략(git flow)

git flow를 사용하기에, 이에 맞게 main, release, feat, hotfix, dev 5개 브랜치를 사용하기로 정하였다. 

PR 완료 시, 출발 브랜치는 전부 자동 삭제되도록 설정하였다.

 

Main 브랜치 - 배포용

실제 서비스에 사용되는 브랜치. 배포용.

 

• main은 release/**/* 와 hotfix/**/* 만 PR 허용

/**/* 는 Github Ruleset에서 브랜치/태그 패턴을 정의할 때 사용하는 fnmatch 문법이다.

release/*만 한다면 -> release/1, release/2 는 가능. 하지만 release/1/1 불가.

release/**/*설정 시 -> 여러 개의 슬래시를 포함할 수 있음. 더 유연한 설정.

 

dev 브랜치 - 개발용(추후 개발서버 배포 고려)

feat 개발 모음용. 개발된 기능들을 총망라하여, 통합 테스트 진행용 브랜치.

 

• dev는 feat/, hotfix/ 만 PR 허용

feat/ 브랜치 - 기능 개발용

서비스 기능 관련 개발시, dev 브랜치에서 feat 브랜치를 분기하여 개발 후 dev에 PR 진행.

feat 브랜치에는 되도록 서비스와 직접적으로 관련된 기능에 사용

 

 

hotfix/ 브랜치 - 개발자용/긴급 수정용 브랜치

main, dev 브랜치에서 분기해서 개발 후, main 브랜치로 직접 PR. 아래 내용에 해당하는 경우만 hotfix 브랜치 사용.

정상적인 기능개발-테스트-릴리즈 과정을 거치지 못하는 모든 내용에 사용.

 

1. 서비스 오류 긴급 수정시
2. CI/CD 나 Github Workflow 수정/개발 시
3. Docs 관련 개발 시
4. 기타 서비스의 기능과 직접적인 관련이 없는 내용 - 개발자 위주 내용

• hotfix/는 dev, release, main 브랜치로 PR 허용

 

release 브랜치 - 배포 직전, 버저닝 용

feature 개발이 dev 브랜치에 모이면, 해당 내용을 모아 release 브랜치로 PR.

이후 테스트를 더 거치고, 배포할 준비가 되면 main 브랜치로 PR해서 merge 진행.

 

• release는 dev, hotfix/ PR 허용
• release/1.1.1, 1.1.2 이렇게 태그 변경

 

 

 

 

Flow

 

 

 

 

github action(workflows)를 활용

위 브랜치 내용을 적용하기 위해서는, 일반적인 branch 규칙 설정으로는 부족하다. 따라서, github action을 통해 브랜치 룰을 지키는 PR인지 확인하는 과정을 workflows에 추가했다.

name: 브랜치 규칙 체크

on:
  pull_request:
    types: [opened, reopened, synchronized, edited]

jobs:
  check-branch-rule:
    runs-on: ubuntu-latest
    steps:
      - name: 브랜치 보호 규칙 준수 여부 확인
        run: |
          TARGET_BRANCH="${{ github.base_ref }}"
          SOURCE_BRANCH="${{ github.head_ref }}"
          
          echo "Target Branch: $TARGET_BRANCH"
          echo "Source Branch: $SOURCE_BRANCH"

          # ---------------------------------------------------
          # 1. Main 브랜치 보호 규칙
          # main은 release/* 와 hotfix/* 만 merge 허용
          # ---------------------------------------------------
          if [[ "$TARGET_BRANCH" == "main" ]]; then
            if [[ ! "$SOURCE_BRANCH" =~ ^release/ ]] && [[ ! "$SOURCE_BRANCH" =~ ^hotfix/ ]]; then
              echo "Error: 'main' 브랜치에는 'release/' 또는 'hotfix/' 브랜치만 병합할 수 있습니다."
              exit 1
            fi
          fi

          # ---------------------------------------------------
          # 2. Release 브랜치 보호 규칙
          # release/* 로의 merge는 hotfix/* 와 dev 만 허용
          # ---------------------------------------------------
          if [[ "$TARGET_BRANCH" =~ ^release/ ]]; then
            if [[ "$SOURCE_BRANCH" != "dev" ]] && [[ ! "$SOURCE_BRANCH" =~ ^hotfix/ ]]; then
              echo "Error: 'release' 브랜치에는 'dev' 또는 'hotfix/' 브랜치만 병합할 수 있습니다."
              exit 1
            fi
          fi
          
          # ---------------------------------------------------
          # 3. Dev 브랜치 보호 규칙
          # dev 로는 feat/*, hotfix/*, release/*, main 허용
          # ---------------------------------------------------
          if [[ "$TARGET_BRANCH" == "dev" ]]; then
            # 허용 목록: feat/..., hotfix/..., release/..., main
            if [[ ! "$SOURCE_BRANCH" =~ ^feat/ ]] && \
               [[ ! "$SOURCE_BRANCH" =~ ^hotfix/ ]] && \
               [[ ! "$SOURCE_BRANCH" =~ ^release/ ]] && \
               [[ "$SOURCE_BRANCH" != "main" ]]; then
              echo "Error: 'dev' 브랜치에는 'feat/', 'hotfix/', 'release/' 브랜치 또는 'main'만 병합할 수 있습니다."
              echo "현재 소스 브랜치: $SOURCE_BRANCH"
              exit 1
            fi
          fi

          echo "Branch rule check passed!"

 

dev브랜치에 release랑 main 설정이 들어갔는데, 이는 추후에 수정해야 할 듯 하다.

 

Branch 전략에 추가하는 법

 

settings->branches->Add branch ruleset 에서

위 항목을 활성화한 다음, check-branch-rule을 입력하여 github workflow를 찾아 통과할 때만 업데이트(merge) 가능하도록 설정할 수 있다.