[Git] GIT-FLOW 전략을 활용해 배포하기

Git-flow로 배포 자동화

오늘은 리로깅 프로젝트에서 실제로 적용한 Git-flow 배포 전략을 정리한다.
많은 프로젝트에서 사용하는 Git-flow를 어떻게 세팅하고 자동화하는지, 처음부터 끝까지 정리해보자.

0. Git-flow가 뭔데

Git-flow는 Git 브랜칭 전략 중 하나이다. 배포 주기가 있는 프로젝트에서 많이 사용한다.
체계적으로 버전 관리를 할 수 있고, 여러 개발자가 협업할 때 유용하고 배민이 깃 플로우 관련한 블로그를 포스팅 해 유명하다.

우린 Git-flow를 사용하고 있어요

1. 브랜치 구조 이해하기

Git-flow는 크게 5가지 브랜치를 사용한다.

main (프로덕션 / 실제 유저들이 사용하는)
  ↑
release/* (릴리스 준비)
  ↑
develop (테스트 서버)
  ↑
feature/* (기능 개발)
hotfix/* (긴급 수정)

• main: 실제 서비스되는 프로덕션 코드
• release: 다음 배포를 준비하는 브랜치
• develop: 개발자들이 공유하는 브랜치
• feature: 새로운 기능 개발
• hotfix: 긴급한 버그 수정

2. 실제 개발 프로세스

2-1. 새로운 기능 개발하기

# develop 브랜치에서 시작
git checkout develop
git pull origin develop

# feature 브랜치 만들기
git checkout -b feature/login

# 열심히 코딩...

# 변경사항 커밋
git add .
git commit -m "feat: 로그인 기능 구현"

# 브랜치 푸시
git push origin feature/login

이후 GitHub에서 PR(Pull Request) 생성하기

2-2. 릴리스 준비하기

# release 브랜치 생성
git checkout -b release/v1.0.0 develop

# 버전 정보 수정
npm version 1.0.0

# 변경사항 푸시
git push origin release/v1.0.0

3. GitHub Actions로 자동화

.github/workflows/deploy.yml 파일을 만들자

name: Deployment

on:
  push:
    branches:
      - develop
      - main
    tags:
      - 'v*'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set environment
        id: env
        run: |
          if [[ $GITHUB_REF == refs/tags/* ]]; then
            echo "env=production" >> $GITHUB_OUTPUT
          elif [[ $GITHUB_REF == refs/heads/develop ]]; then
            echo "env=staging" >> $GITHUB_OUTPUT
          fi

      - name: Deploy to staging
        if: steps.env.outputs.env == 'staging'
        run: |
          # 테스트 서버 배포 스크립트

      - name: Deploy to production
        if: steps.env.outputs.env == 'production'
        run: |
          # 프로덕션 서버 배포 스크립트

• develop 브랜치에 푸시되면 테스트 서버에 배포
• 태그가 푸시되면 프로덕션 배포가 자동으로 이루어짐

4. PR 템플릿 만들기

.github/pull_request_template.md 파일 생성

## 변경사항 설명
- 

## 테스트 완료 여부
- [ ] 단위 테스트
- [ ] 통합 테스트
- [ ] QA 테스트

## 관련 이슈
- #이슈번호

5. 실제 릴리스 과정

1. 테스트 완료 후 main 브랜치로 병합

git checkout main
git merge release/v1.0.0

2. 태그 생성하고 푸시

git tag -a v1.0.0 -m "version 1.0.0"
git push origin v1.0.0

3. 변경사항 develop에도 적용

git checkout develop
git merge release/v1.0.0

6. 이렇게 하면 좋은 점

1. 코드 품질 관리

   • PR 리뷰로 코드 품질 유지
   • 테스트 자동화 가능

2. 배포가 안전

   • 실수로 배포하는 일이 없음
   • 롤백이 쉬워짐

3. 버전 관리가 깔끔

   • 체계적인 버전 히스토리
   • 릴리스 노트 자동화