Git Flow

이우철·2025년 8월 23일

branch 를 나누어 무리없는 협업을 합니다

main > develop > feature > release > hotfix

  • main brach : 정식 버전의 취합, 외부 오픈된 최종 버전
  • develop brach : 개발중인 버전 취합, feature 에서 신규로 개발된 내용들을 이곳에 합치고 테스트, main으로 합치기 위해선 release 브랜치를 따서 해당 브랜치에서 테스트 및 검수 진행 후 메인으로 합치게 됨
  • feature brach : 신규 기능 발생(필요) 시 feature branch를 새로 따고, 거기에 내용을 작성함, 작성한 내용은 이후 develop 으로 취합(머지)
    예시) 사용자통계 기능의 추가일 경우
    feature/user-stat 로 브랜치를 신규 생서하고 작업 진행
  • release branch : develop 의 내용을 메인으로 합치기 전에 생성하여 해당 릴리즈 브랜치에서 검증 및 테스트 진행함. 최종 메인 머지 시 개발(develop) 에도 머지를 해줌 (개발 상태 최신화)
  • hotfix branch : 실 서비스 상황(메인)에서 이슈 발생 시 (빠른 처리 등) develop 으로 가는 정식 루트 말고 핫픽스 브랜치를 열어서 빠르게 개발하여 버그 수정 후 메인에 머지함. 이때 develop에도 머지 필요

🌱 feature 브랜치

  • 언제 PR? 기능 개발이 완료되었을 때
  • 어디로 PR? develop 브랜치로
  • 목적: 새로운 기능을 통합하고 테스트 환경에 반영하기 위함
  • 팁: 작은 단위로 자주 PR을 보내는 게 리뷰와 병합에 유리해요

🧪 develop 브랜치

  • 언제 PR? 여러 기능이 통합되고 릴리스 준비가 되었을 때
  • 어디로 PR? release 브랜치로
  • 목적: QA 및 최종 테스트를 위한 릴리스 준비
  • 팁: 이 단계에서 버전 넘버나 문서 업데이트도 함께 진행돼요

🚀 release 브랜치

  • 언제 PR? QA가 끝나고 배포 준비가 완료되었을 때
  • 어디로 PR? main 브랜치로
  • 목적: 실제 배포를 위한 코드 병합
  • 추가 PR: release → develop도 병행해서, develop에 릴리스 변경사항을 반영해야 해요

🛠️ hotfix 브랜치

  • 언제 PR? 긴급 수정이 완료되었을 때
  • 어디로 PR? main 브랜치와 develop 브랜치 모두
  • 목적: 빠른 배포와 동시에 개발 브랜치에도 수정사항 반영
  • 팁: hotfix는 main에서 바로 파생되며, 배포 후 develop에도 꼭 병합해야 해요
  • github 예를 들어보자

🔧 feature 브랜치 → develop

  • 언제: 기능 개발 완료 시
  • 어떻게:
  • PR 제목: feat: 로그인 기능 추가
  • 라벨: feature, needs review
  • 리뷰어 지정: 팀원 중 관련 기능 담당자
  • 체크리스트: 테스트 완료 여부, 문서화 여부 등

🧪 develop → release

  • 언제: 여러 기능이 통합되고 QA 준비가 되었을 때
  • 어떻게:
  • PR 제목: release: v1.2.0
  • 라벨: release, ready for QA
  • QA 팀이 리뷰 후 승인

🚀 release → main

  • 언제: QA 통과 후 실제 배포 직전
  • 어떻게:
  • PR 제목: deploy: v1.2.0 to production
  • 라벨: production, approved
  • 병합 후 태그 생성: v1.2.0

🛠️ hotfix 브랜치 → main & develop

  • 언제: 긴급 수정 완료 시
  • 어떻게:
  • PR 제목: hotfix: 로그인 오류 수정
  • 라벨: hotfix, urgent
  • 병합 후 main에 배포, develop에도 동일한 수정 반영

💡 GitHub에서 PR 관리 팁

  • 템플릿 사용: .github/PULL_REQUEST_TEMPLATE.md 파일로 PR 양식 통일
  • 자동 라벨링: GitHub Actions로 브랜치 이름에 따라 라벨 자동 지정
  • PR 리뷰 규칙: 최소 1명 이상 승인 후 병합, CI 통과 필수 등
  • PR template 예시 및 설정
  1. 예시
## 📌 개요
<!-- 이 PR이 어떤 작업을 포함하는지 간단히 설명해주세요. -->

## ✅ 작업 내용
<!-- 주요 변경 사항을 bullet point로 정리해주세요. -->
- [ ] 로그인 기능 구현
- [ ] JWT 토큰 발급 로직 추가
- [ ] 로그인 실패 시 에러 메시지 처리

## 🔍 관련 이슈
<!-- 관련된 이슈 번호를 연결해주세요. -->
- close #123

## 🧪 테스트 방법
<!-- 어떻게 테스트했는지, 어떤 환경에서 확인했는지 작성해주세요. -->
1. 로그인 페이지에서 이메일/비밀번호 입력
2. 유효한 정보일 경우 토큰 발급 확인
3. 잘못된 정보일 경우 에러 메시지 출력 확인

## 📸 스크린샷 (선택)
<!-- UI 변경이 있다면 스크린샷을 첨부해주세요. -->
| 변경 전 | 변경 후 |
|--------|--------|
| ![before](url) | ![after](url) |

## 💬 기타 참고 사항
<!-- 리뷰어가 알아야 할 추가 정보가 있다면 작성해주세요. -->
- 로그인 API는 백엔드와 연동 완료
- 추후 리팩토링 예정
  1. 설정
  • 프로젝트 루트에 .github 폴더 생성
  • 그 안에 PULL_REQUEST_TEMPLATE.md 파일 생성
  • 위 내용을 복사해서 저장하면 끝!

cf. Trunk=based
main branch 1 way 하나만 운영하며 필요 시 feature로 분기 후 다시 메인으로 합침

profile
개발 정리 공간 - 업무일때도 있고, 공부일때도 있고...

0개의 댓글